My Journey in Learning Domain-Driven-Design part1
What is Domain-Driven-Design?
Domain-Driven Design is an approach to software development that centers the development of programming a domain model that has a rich understanding of the processes and rules of a domain.
“Domain” in Domain-Driven-Design refers to the “business logic” or “business problem” we want to solve with our solution.
in Domain-Driven-Design our domain is the heart of our architecture. as we want to focus on the business logic excluding any other technical aspects
Domain-Driven-Design Main Parts
as we said that DDD is an approach to design software it consists of two parts:
1- Strategic modeling
2- Tactical modeling
Strategic modeling:
The main objective is to define the Core-Domain, Sub-Domain, Bounded contexts, the Ubiquitous Language, and the Context Maps together with the entire project team, which are the domain experts and the technical team.
Let's Clarify these terms
Core-Domain:
Core-Domain is the critical and fundamental part of the business that gives you a competitive advantage and is a foundational concept behind the business as you will employ the smartest resources of your company to develop it.
Sub-Domain:
Sub-Domain is a supporting feature or can be as simple as
a set of algorithms that, while essential to the business solution, are not part of the distinguished by the Core-Domain.
Bounded context:
A Bounded Context is an explicit boundary within which a domain model exists. Inside the boundary, all terms and phrases of the Ubiquitous Language have a specific meaning, and the model reflects the Language with exactness. as [Vaughn Vernon] speaks in his book.
Banking Context: An Account maintains a record of debit and credit transactions indicating a customer’s current financial state with the bank.
Literary Context: An Account is a set of literary expressions about one or more related events over a time span.
Example: “Amazon.com sells the book Into Thin Air: A Personal Account of the Mt. Everest Disaster”
The Ubiquitous Language:
is a shared team language. It’s shared by domain
experts and developers alike. In fact, it’s shared by everyone on the project
team. No matter your role on the team, since you are on the team you use the
Ubiquitous Language of the project.
Context Maps:
The Context Map of a project can be expressed by drawing a simple diagram that shows the mappings between two or more existing Bounded Contexts. The drawing illustrates how the actual software Bounded Contexts in the solution space are related to one another through integration. This means that the more detailed way to express Context Maps is as the source code implementations of the integrations
Tactical modeling:
tactical modeling focuses more on the implementation part which will be the fun part for us as developers. the tactical modeling helps us to create an elegant Domain Model using it’s building blocks.
Entities:
An object defined primarily by a unique identity is called an “Entity”. Entities have special modeling and design considerations. They have life cycles that can radically change their form and content, but a thread of continuity must be maintained. Their identities must be defined so that they can be effectively tracked. Their class definitions, responsibilities, attributes, and associations should revolve around who they are, rather than the particular attributes they carry.
ValueObjects:
An Object that has no unique identity. It measures, quantifies, or describes a thing in the domain. It models a conceptual whole by composing related attributes as an integral unit. It can be compared with others using Value equality. Examples of objects that are commonly modeled as ValueObjects dates, times. more detailed objects such as a person’s full name composed of first, middle, last name, and title attributes; and others such as currency, colors, phone numbers, and postal addresses.
Service:
A Service in the domain is a stateless operation that fulfills a domain-specific
task. Often the best indication that you should create a Service in the domain
model is when the operation you need to perform feels out of place as a method on an Aggregate or a Value Object.
Aggregate:
An Aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes that is okay to cascade delete all objects inside that cluster. The Parent Entity of this cluster receives the name of Aggregate Root.
Repositories:
Repositories are mainly used to deal with storage, they abstract concerns about data storage. They are responsible for persisting Aggregates.
Factories:
Factories are used to provide abstraction in the construction of an Object and can return an Aggregate Root, an Entity, or a Value Object. Factories are an alternative for building objects that have complexity to be built via the constructor method.
Events:
Events indicate significant occurrences that have occurred in the domain and need to be reported to other stakeholders belonging to the domain. It is common for Aggregates to publish events.
References:
- Domain-Driven Design by Eric J. Evans
- Implementing Domain-Driven Design by Vaughn Vernon
- Domain-Driven Design Fundamentals course By Julie Lerman and SteveSmith
Let me know which model you want me to dig deeper into (strategic or tactical), If you have any questions or feedback, just leave me a comment.
