Skip to content


November 21, 2009
tags: ,

Here are some points from Evan’s talk on Domain Design from the site: DDD

  • Creative collaboration of domain experts and software experts
  • Exploration and experimentation
  • Emerging model shaping a ubiquitous language
  • Explicit context boundaries
  • Focus relentlessly on the core domain

So basically DDD defines the “values” that should dictate the software design.

A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence.

Find order in this seemingly chaotic amount of information. Order to the point that the system is described in an intense precision and clarity.

Domain experts know their area of expertise well, but they organize and use their knowledge in a specific way, which is not always the best to be implemented into a software system.

Those concepts may come out unpolished and disorganized, but nonetheless they are essential for understanding the domain. You need to learn as much as possible about the domain from the experts. And by putting the right questions, and processing the information in the right way, you and the experts will start to sketch a view of the domain, a domain model. This view is neither complete nor correct, but it is the start you need. Try to figure out the essential concepts of the domain.

The Ubiquitous Language: A core principle of domain-driven design is to use a language based on the model. Since the model is the common ground, the place where the software meets the domain, it is appropriate to use it as the building ground for this language.
How do we approach the transition from model to code
Closely relate domain modeling and design. The model should be constructed with an eye open to the software and design considerations. Tightly relating the code to an underlying model gives the code meaning and makes the model relevant. Analyst must do some code and Coder must learn to express a model through the code.

Code becomes an expression of the model
Partition a complex program into LAYERS. Develop  a design within each LAYER that is cohesive and that depends only on the layers below.
UI ->  Application (no state/ no b/s logic here – only application state )    ->  Domain (only b/s logic)  -> Infrastructure (DB/ui library handling etc)
When domain-related code is mixed with the other layers, it becomes extremely difficult to see and think about.
Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical

ENTITY:      Implementing entities in software means creating identity.
Recommended to select as entities only those objects which conform to the entity definition. And make the rest of the objects VALUE OBJECTS. Recommended that value objects be immutable

SERVICE : Important behavior of the domain, operation stateless, does not naturally belong to entity,vo and refers to objects in domain
Segregating service in a specific layer is a tricky process that needs to be done.
MODULES: Group similar classes together (software code should have a high level of cohesion and a low level of coupling) Communicational cohesion is achieved when parts of the module operate on the same data. Functional cohesion is achieved when all parts of the module work together to perform a well-defined task.
Interfaces of modules 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.
Defines object ownership and boundaries.
Clean up actions
1. Associations which are not essential for the model should be removed. They may exist in the domain, but they are not necessary in our model, so take them out.
2. Multiplicity can be reduced by adding a constraint
3. Bidirectional associations can be transformed in unidirectional ones
Difficult to guarantee the consistency of changes to objects in a model with complex associations. Enforce the invariants ( Rules which have to be maintained whenever data changes)
Factories and Repositories are two design patterns which help us deal with object creation and storage.

one unit : demarcated by boundary, one root, root is an entity.
root – holds rfc of others.
Aggt: only visible by the root
entities are local to aggt
Root manages control and enforces invariants.
passes copies of VO to outside. (Root of aggregate is entity)
Factory: Specially assigned the task of object creation process.
Entity : ID and modifiable, VO – no id and immutable.
Repositories: Fetching of entities from db causes breaking of logic of domain.
Provide repositories only for aggregate roots that need direct access.
Use a specification class eg: Criteria for doing the selection of right entity.
Factory/Repositry: Take care of life cycle of domain objects. While the Factory is concerned with the creation of objects, the Repository takes care of already existing objects.
The Factory should create new objects, while the Repository should find already created objects. When a new
object is to be added to the Repository, it should be created first using the Factory, and then it should be  given to the Repository which will store it
createCust = factory (pure domain)
addCustomer = repository (infrastructure = database)
A model that sloughs off the superficial and captures the essental is a deep model. This should make the software more in tune with the way the domain experts think and more  responsive to the user’s needs.
Constraint (invariant), Process (strategy – services) and Specification.
Processes is to use a Service. If there are different ways to carry out the process, then we can encapsulate the algorithm in an object and use a Strategy.
Specification – club checking the rules in this class and hand it over the customer(entity reference) and it will validate the booleans and accordingly action can be taken. Rule clubbing.
Internal consistency of a model.
Several models well integrated can evolve independently as long as they obey the contract they are bound to. Each model should have a clearly delimited border,
and the relationships between models should be defined with precision.
A model should be small enough to be assigned to one team
The context of a model is the set of conditions which need to be applied to make sure that the terms used in the model have a specific meaning , sCOPE, BOUNDARIES.
A Bounded Context is not a Module. A Bounded Context provides the logical frame inside of which the model evolves. Modules are used to organize the elements of a model, so
Bounded Context encompasses the Module.   breaking down the system into ever-smaller contexts eventually loses a valuable level of integration and coherency
Continuous Integration applies to a Bounded Context, it is not used to deal with relationships between neighboring Contexts.  Context Map is a document which outlines the different Bounded Contexts and the relationships between them. – ASSEMBLY
A Core Domain is not usually created in one final step. There is a process of refinement and successive refactorings are necessary before the Core emerges more clearly
Identify cohesive subdomains that are not the motivation for your project. Factor out generic models of these subdomains and place them in separate Modules. Leave no trace of your specialties in them.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: