Domain-Driven Design is quite a new approach to model complex business applications. It helps all stakeholders involved in a software development project to find a common communication ground. It provides software developers with an approach to communicate in an understandable way with the business (domain) owners and vice versa. Reading a few articles and the presentation “Domain-Driven Design – a way of modeling complex business domains” by Sławomir Sobótka at Java Developer’s Days 2011, inspired me to write this blog post. Below I will present a short introduction to DDD.
What is DDD and what can you use it for?
DDD is an approach to software development which strongly focuses on modeling the core business concepts – model – which in general is the most complex part of a business systems. DDD is neither a technology nor a methodology. It simply provides the best practices to take the right decisions to accelerate software projects for complicated domains.
The term itself was introduced in 2003 by Eric Evans after a publication of his book – „Domain-driven Design: Tackling Complexity in the Heart of Software”.
DDD applies to projects where the model is:
- the reason of project creation
- the heart of the system, it’s the biggest value of the system
- the factor that provides the real, competitive advantage to the organization
- the biggest challenge of the whole project.
DDD provides all project stakeholders a common ground
The model is the knowledge base of all the business rules and behavior. But be aware that we cannot rely on a database model to store our model, because the database is a static structure, which represents only the state of business objects. Additionally, the database is usually created when there is not enough information about the business domain, so when in fact we don’t understand it.
Sometimes a model can be perceived as a result of an analyst’s work. Unfortunately, too often their abstraction level is hard to implement by developers because they have problems understanding it. This is why ubiquitous language is so important. All project attendees (domain expert(s), project manager(s), architect(s) and developer(s)) should use the same level of abstraction to prevent misunderstandings.
Therefor, the project should exist from one kind of a model. Using the DDD approach means that the model is a common ground agreement between the domain expert and the project team. The DDD approach modifies the classical 3-tier architecture which consists of a presentation, logic and data access layer. DDD divides the logic into two parts:
- Application logic and
- Business logic.
The Application logic controls the business flow described by the use cases or user stories, besides it encapsulates all technical stuff like security and transactions. The Business logic focuses on the domain only. It presents a low-level business infrastructure. This approach makes the business logic portable between different frameworks and/or technologies.
The DDD building blocks
DDD defines a number of standard “blocks” (Building Blocks) which are used to design a domain. These Building Blocks are a part of a pattern language concept and they describe the roles (responsibilities) of the domain objects.
In the DDD approach there are different main Building Blocks mentioned below.
Entity
The basic unit in every ORM (object-relational mapping), which holds state and is identified by a key. In DDD, entities perform some small business logic as well.
Example: Product.
Aggregate
The representation of collections of objects that are bound together by a root entity (aggregate root). Aggregates are the main units of work in DDD. They should encapsulate their implementations in order to guarantee the consistency of changes.
Example: Order which holds information about OrderItems (external objects don’t know anything about them) and a total sum. It has business methods which can be used in order to add/remove new Products or to calculate the sum.
Value Object
Usually used as an attribute in Entities or Aggregates. Value object is used to encapsulate more complex information (data).
Example: Order has an attribute sum which is a Money type. Money is a value object; it stores information about an amount, rounding, currency and the date of an exchange rate.
Service
It executes all low-level business operations.
Example: InvoicingService is used to create invoices.
Policy
Represents the concrete implementation of abstract business behavior (rule). From the OOD (Object Oriented Desing) point of view, a policy is an equivalent to the strategy pattern.
Example: RebatePolicy is an interface which is used by the model core to calculate rebates. But there can be many different policies to calculate rebates (VIP rebate, seasonal rebate etc.). Adding a new rebate policy means nothing more but implementing a RebatePolicy interface, so the model core doesn’t have to be changed, meanwhile gaining on flexibility.
Factory
Encapsulates the process of Entity, Aggregate and Policy creation. It can also validate the state of the object being created.
Repository
It manages the persistence of entities and aggregates. Repository can retrieve an aggregate by id and/or save its state. Unlike normal DAO (Data Access Object) Repository it doesn’t contain a number of finder methods (findByUsername, findByEmail and so on). Instead it uses the specification design pattern in order to obtain objects regardless of search criteria. Please refer to Eric Evans’ book if you want to get more info about the Specification design pattern)
Event
Describes important business occurrences.
Example: The Order has been confirmed. This event can trigger many different operations which can be done independently from each other, some of these operations can even be executed asynchronously.
Use DDD to model your projects showing the business you understand their needs
DDD is a very interesting approach and might be helpful if you need to model complex business domains. The key element in this whole process is intensive communication with the domain expert to figure out their particular domain needs in an iterative way.
Resources:
- Eric Evans’ book – “Domain-driven Design: Tackling Complexity in the Heart of Software”
- Wikipedia
- Domaindrivendesign.org
1 comment
Comments are closed.