Domain-Driven Design: Two basic premises

In the post I want to discuss about two basic Domain-Driven Design premises which stand on the base of all other DDD principles, patterns, and practices. DDD principles, patterns, and practices described by Eric Evans are not something invented by him, but are something that were discovered and used long experience path by many folks. So, all DDD goodies have just two simple premises which I will cover in the post.

Nowadays Complexity

Before to dive in the premises lets discuss how they evolved. Nowadays more and more are automated various business domains (Domain - particular field of knowledge, e.g. Banking, Accounting, Assurance, E-Commerce, etc.. ) . The complex human work is automated as much as possible to reduce costs and earn velocity. All these are primary factors for successful business and top market place and the business competition. If to compare nowadays software situation with 90’ time span, when a lot of software solutions were common applications, now custom solutions are predominant, because: for a successful competition is necessary to be one step further. The tendency is that business complexity grows continuously dragging in software solution into “hell”. There are a lot of other things that can make software development complex but as we can see core of the complexity is business domain itself.

In order to automate enterprise systems, complexity is the key factor that eventually can’t be omitted ONLY CONTROLLED. Of course there are two types of complexity: 1. essential – complexity that is reasonable and unavoidable that can’t(or shouldn’t) be omitted 2. accidental - complexity which is non-essential to the problem to be solved So, by following the DDD premises we will be able better highlight and concentrate on the essential domain complexity.

Two main DDD premises

Below are two premises that are also two DDD principles where all starts from. All other principle, patterns and practices are built on these principles OR they are compatible complementing each other.

1. Primary focus should be on the domain and domain logic

2. Complex domain designs should be based on a model

First principle says that for most of the projects primary focus should be on business domain and domain logic. That is true for most of the projects but for a part of the project it isn’t. For example:

1. For device that handle small logic but very fast such as routers, modems, etc…

2. Frameworks or technical libraries where main focus is not a business domain

Second principle says that design should be based on models. Model is very generic term, a model is a pattern, plan, representation (especially in miniature), or description designed to show the main object or workings of an object, system, or concept.

Why models? Let’s see…

Humans use models starting from beginning of its history, and use them in various scopes:

1. Explain (very distinct from predict)
2. Guide data collection
3. Illuminate core dynamics
4. Suggest dynamical analogies
5. Discover new questions
6. Promote a scientific habit of mind
7. Bound (bracket) outcomes to plausible ranges
8. Illuminate core uncertainties.
9. Offer crisis options in near-real time
10. Demonstrate tradeoffs / suggest efficiencies
11. Challenge the robustness of prevailing theory through perturbations
12. Expose prevailing wisdom as incompatible with available data
13. Train practitioners
14. Discipline the policy dialogue
15. Educate the general public
16. Reveal the apparently simple (complex) to be complex (simple)
17. Etc…

As an example I’ve got Atom Model. Which in translation means uncuttable, something that cannot be divided. On the right is modern model of the Atom which is evolution of the first model from the left.

So, initial model from the left is initial “Atom” model, where the "Atom" term comes/starts from. That was a start for next models and theories. Scientists learn and discovered new models with new atom model structures through various experiments. The new model structures evolved to match new obtained results from the experiments, so model evolved through time and discussions. Even now, using the most powerful microscopes Atom structure can’t be revealed, that is why were a lot of models based on various theories and if a model and its theory doesn’t pass an experiment then the model and its theory is thrown.

Models rarely represent something real or right. They could and are, more valuable when are not realistic. You could think that the best models are wrong. Yes, But they are fruitfully wrong! Models are just to highlight abstractions.

"Art is a lie that helps us see the truth." – Picasso
"All models are wrong, but some are useful." - George Box

Even music has a Model!

Models can abstract very abstract things in order to materialize them for a better perception. From first sight Music is very abstract “concept” that is hard to imagine a model for it.

This is a model of the music, the model allows to have a written form of music, to show some not obvious aspects that can’t be heard, to communicate. In music history were a lot of cases when symphonies were composed by completely deaf musicians. Again, above form is modern form to write music, the form was very different in incipient forms.

Best Model?

Can you answer for yourself which model is the best model?

Of course, it depends. Depends on the context. If we need a political situation then first model is better if we need to explore internal earth structure then second model is better. Even both models represent earth, each model shows its abstractions, and has its context. Also you can notice that the model represent something real but model itself is far to be real, even so it is very valuable for its specific purpose.

As a conclusion for the theory, here is a definition of the model from DDD perspective:

Domain Model - is a rigorously organized and selective abstraction of the (Business) Domain knowledge.

Conclusion

The two DDD premises are very simple abbreviations for a set of practices that are used in various domains to handle complexity. Focus to domain logic based on models is very important to control complexity, as you can see not only in software development.

Refernces & Resources

“Why Models” - http://jasss.soc.surrey.ac.uk/11/4/12.html
“Domain-Driven Design: Tackling Complexity in the Heart of Software” - http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
For introduction to DDD and more resources DDD take a look to my post: http://weblogs.asp.net/arturtrosin/archive/2009/02/09/domain-driven-design-learning.aspx

Thank you,

Artur Trosin