Domain Driven Design: domain what?

Domain Driven Design is an approach with many applications which is often used in the process of domain design, communication organization, implementation of business assumptions or support in project management. If you create complex systems and would like to learn how to do it better, then this article is for you.

Reflect business problems in your code

Domain Driven Design is an approach that assumes the best understanding of business rules and problems and their reflection in the domain model and successively in implementation. According to DDD, code is based on known and previously understood business assumptions, which are usually presented by a domain expert – a person who has the most knowledge of business aspects.

The names of classes, variables and other implementation components should be consistent with a business nomenclature. Maintaining consistency in the naming of implementation components is not an easy task. In order to correctly replicate the business, it is recommended to introduce “ubiquitous language”. It includes predefined words and phrases that are understandable to both, the expert and the implementation team.

The author and originator of this approach is Eric Evans, who in 2003 published a book entitled: “Domain-Driven Design: Tackling Complexity in the Heart of Software”, which covered this issue extensively.

Building blocks of Domain Driven Design

As I mentioned before, DDD is mainly about mapping business assumptions in code. Each element of the business is described as a clear implementation component. The different pieces of business can be expressed with many different implementation elements, these elements are called Building Blocks and directly create the code in the domain. Among the Building Blocks, the following can be distinguished:

• aggregates,
• entities,
• policies,
• services,
• factories,
• builders,
• domain events.

What is a domain?

According to the definition in the Oxford Dictionary, the word “domain” may be described as: “A specified sphere of activity or knowledge”. This is nothing more than a certain thematic area in business, which is reflected in code. An implementation is created with consistency, business rules, and many other factors, by using Building Blocks. A domain can also be called a “group” or a “module”, but the meaning will be the same: mapping a group of business concepts into an implementation.

Finding coherent and atomic domains is one of the most difficult, if not the most difficult, processes included in the DDD approach. It requires a deep understanding of the business needs and concepts presented by the domain expert.

The figure below shows an example of a simple invoice billing domain:

When to use Domain Driven Design?

Introducing this approach is expensive in the initial phase of the project, but the cost is reduced along with the duration of the project, due to the initial, thorough understanding of all business assumptions. The high initial cost is due to the need to organize meetings between the development team and the domain expert. Depending on the complexity and size of the project, there may be many meetings. It follows that it is not worth using DDD in small projects such as multiple CRUD, which are usually not complicated. 

If your project involves the implementation of a large system with extensive business assumptions, you should consider using Domain Driven Design.

Read more: UI for mobile apps – How to create a nice and useful product?

Summary

Developing software in accordance with Domain Driven Design puts emphasis on a thorough understanding of the problems and needs of business. Thanks to mutual understanding (client – development team), code is easier in further development. Implementation based on DDD makes all the details of business processes visible, which eliminates the problems of missing or incorrect understanding of certain aspects described by the business.

Recommended For You:
6 reasons why your next business project needs product design workshops
Design Sprint in product design: 4 things you need to know
Domain Driven Design: aggregates implementation
Domain Driven Design: discovering domains
What’s the difference between software architecture and design?
Domain Driven Design: domain building blocks