Building blocks

Both MVC and DDD provide us with something really powerful. They allow us to decompose a typical enterprise code base into smaller building blocks. These building blocks provide abstractions which are somewhere between an application and a class. A building block consists of multiple classes which has same type of responsibility in the code base. e.g. there are many controllers in the presentation layer of an application.

Identifying the domain specific building blocks

While DDD and MVC provides us with individual building blocks, we can also identify blocks which are specific to our application and other patterns that we are following.

Package (namespace) based on the building blocks

We can use these boundaries in our code to structure the code along these lines. Since these are derived from the patterns it lends to readability of the code. If we follow this rule we answer one big question where does what code go. If we don't know where a particular class goes, the team should have a discussion about it. This often leads to:

- This class is not required because it is doing what classes belonging to other building blocks should be doing.

- This class implements something orthogonal to our code and may be we should look for any tool/library out there which does the same thing. If we cannot find one we should probably push such code in a different infrastructure related module.

- We really need a new building block.

Readme for every building block

It is easy to document a class by putting some documents on the class or method. There is no language mechanism to do the same for package. A simple thing which can be done for this is to put a small readme.txt inside the package folder and check-in to the source control.