“Domain Driven Design” or DDD and Modular Architecture

Review “Domain Driven Design” or DDD:

“Domain Driven Design is a vision and approach for designing a domain model that reflects a deep understanding of the business domain. This book is a short, quickly-readable summary and introduction to the fundamentals of DDD; it does not introduce any new concepts; it attempts to concisely summarise the essence of what DDD is, drawing mostly Eric Evans’ book.”

Some links below:

InfoQ on DDD

“For a large and complex application, the model tends to grow bigger and bigger. The model reaches a point where it is hard to talk about as a whole, and understanding the relationships and interactions between different parts becomes difficult. For that reason, it is nacessary to organize the model into modules. Modules are used as a method of organizing related concepts and tasks in order to reduce complexity.

Modules are widely used in most projects. It is easier to get the picture of a large model if you look at the modules it contains, then at the relationships between those modules. After the interaction between modules is understood, one can start figuring out the details inside of a module. It’s a simple and efficient way to manage complexity.

Another reason for using modules is related to code quality. It is widely accepted that software code should have a high level of cohesion and a low level of coupling. While cohesion starts at the class and method level, it can be applied at module level. It is recommended to group highly related classes into modules to provide maximum cohesion possible. There are several types of cohesion. Two of the most used are communicational cohesion and functional cohesion. Communicational cohesion is achieved when parts of the module operate on the same data. It makes sense to group them, because there is a strong relationship between them. The functional cohesion is achieved when all parts of the module work together to perform a well-defined task. This is considered the best type of cohesion.

Using modules in design is a way to increase cohesion and decrease coupling. Modules should be made up of elements which functionally or logically belong together assuring cohesion. Modules should have well defined interfaces which are accessed by other modules. Instead of calling three objects of a module, it is better to access one interface, because it reduces coupling. Low coupling reduces complexity, and increases maintainability. It is easier to understand how a system functions when there are few connections between modules which perform well defined tasks, than when every module has lots of connections to all the other modules.

Choose Modules that tell the story of the system and contain a cohesive set of concepts. This often yields low coupling between modules, but if it doesn’t look for a way to change the model to disentangle the concepts, or an overlooked concept that might be the basis of a Module that would bring the elements together in a meaningful way. Seek low coupling in the sense of concepts that can be understood and reasoned about independently of each other. Refine the model until it partitions according to high-level domain concepts and the corresponding code is decoupled as well.

Give the Modules names that become part of the Ubiquitous Language. Modules and their names should reflect insight into the domain.”

DDD advocates creating a “Ubiquitous Language” between the development team and the customer.

For us, it is the language that the Product Owner uses to communicate his/her understanding of the “Problem Domain”. As a solutions oriented business our focus is on capturing a clear model of the problem domain and designing a solution which perfectly matches that domain.

So the language the Product owner uses is the key! Our Modules should reflect that language and the mental model of the Product Owner.

Leave a Reply