Taming Complex Domains with Domain Driven Design

CopyrightAlbertoBrandolini2008

Taming complex domains with

Domain Driven Design


About me10 years experience in IT, mainly as a consultantTook part in many large scale projects

Government(s)BankingInsurances

A foot in the process, the other in the architecture.Seasoned trainerMy blog: http://ziobrando.blogspot.com

My e-mail: [email protected]

http://ziobrando.blogspot.com/

http://ziobrando.blogspot.com/

mailto:[email protected]

mailto:[email protected]


What are we talking about?

The DDD book, by Eric Evans has been published in 2004, gaining increasing momentum since then.


...from the source

Domain-driven design is not a technology or a methodology.

It is a way of thinking and a set of priorities, aimed at accelerating

software projects that have to deal with complicated domains.


DDD - what it is and why it matters

What it is and why does it matters

This is an approach that goes from small to large scale.



It’s a set of proven modeling techniques especially targeted to complex applications.





It’s a set of proven modeling techniques especially targeted to complex applications.It’s a set of principles and practices

supporting the development process.






supporting the development process.It’s a set of patterns that support a clean and

coherent view of the domain model.







coherent view of the domain model.It’s a set of pragmatic strategies allowing

applications to scale in size and complexity maintaining their integrity.







coherent view of the domain model.It’s a set of pragmatic strategies allowing

applications to scale in size and complexity maintaining their integrity.




Wasn’t OOP enough?OOP original value proposition has been

enhanced in many directions primarily addressing architecture and design issues.

Still, OOP falls short and lacks well established disciplines to model complex domains.

In the past, tools and frameworks have twisted the original OO paradigm silently constraining

domain modeling techniques

Design pattern book?

The original OOP hype was centered on the myth of reuse. Really reusable solutions appeared in the form of patterns (Design patterns, GRASP patterns, Architectural patterns and so on).They primarily focused on design and architecture, also because they were domain-neutral and allowed for potentially higher reusability.

The only notable effort to fill this gap is Martin Fowler’s book Analysis Patterns.


The premise

The primary focus should be on domain and domain logic

Complex domain design should be based on a model

Technology, per se, does not provide a key competitive advantage in building a competitive software.


The ecosystem

Agile Software Development practices should be in place, allowing

short iterations to gather users’ feedback from users

and domain experts.

The Model





Why do we need a model?

A model is a representation of the domain serving a specific purpose.There is no “perfect” model for a

given domain. A good model is tailored on the

given purpose.


Expressing the model

Model and the underlying design must evolve in sync.

Code is the ultimate way to express the model.

Intermediate artifacts, diagrams and docs serve a temporary goal.

Model

Design


Lo-fi UMLMany tools twisted the purpose of UML, focusing

on code generation capabilities, reverse engineering, color gradients and so on.

butModeling activity is too crucial to be performed

in isolation.Heavyweight UML might prevent domain experts

from contributing to the model.Use a valuable subset of UML to communicate effectively with the team and domain experts.

One notable exception is the old TogetherJ, whose roundtrip features might help to keep diagrams and code in-sync. But problems related to isolation and shutting down the communication channel with the domain expert were still open.


The Mindset


Continuous LearningLearning about the underlying domain is often

considered a byproduct or a side-effect.

Many projects sponsor learning new technologies or architectures, but rarely

consider the domain among the valuable topics.

Continuous learning, instead, is a key activity for a successful project, and is the only

way to deliver a useful model


Working with domain experts

Team and domain experts continuously refine their

model and their understanding of the

domain.Communication channel

between the domain expert and the team must

be kept open.


Knowledge crunching

Our job is to be able to translate any domain into the most useful

model.To achieve this goal we must crunch the amount of knowledge available

from domain experts, users, books...


Ubiquitous language

Knowledge about the domain is expressed in a ubiquitous language, allowing domain experts, designers, testers, and developers to share and maintain the

same vision.Terms of the ubiquitous language must be

unambiguous and agreed by all parties.


The Breakthrough

• Learning does not happen brick by brick

• Learning is not a linear process

• A deeper level of knowledge implies refactoring of the existing solution

This is a key moment in DDD. When we recognize that our understanding of the domain has improved also the code must follow. This is tricky and hard to achieve. An exploratory session backed up by tests is often the best solution.


Refactoring the Domain

Our knowledge of the Domain is challenged by Continuous Learning.

The more we learn, the more the existing model must be evolved accordingly.

Brainstorming and Refactoring help experimenting new versions of the domain

model.

Availability of an automated test suite greatly enhances our domain refactoring capabilities.

Our vision of the domain and our implementation must be strictly tied. Consciously leaving a gap between the ideal implementation and the real one complicates domain management providing little value.

This is an argument that an be vigorously opposed by project managers, if they’re thinking short-term. The main weapons to make this option viable are:• having the implementation as close as possible to our understanding of the model (gaps build on gaps)• having a test suite in place, targeted against our domain objects.• Experiment. Assumptions are generally negative: estimations of refactoring tasks are often larger than necessary. Ripple effects are valuable knowledge

Implementing a model:

DDD Building Blocks


Building our modelRegardless of the domain complexity, an application

domain might be represented with specific classes, assuming specific roles and partitioning

the domain model in well structured regions


Building blocks

On a small scale, every domain exposes a peculiar but repeatable structure, organized in families of classes

with specific purposes.Entities

Value ObjectsServicesModules

AggregatesFactories

RepositoriesAggregate Objects

Domain Events


Entities

• Objects with an identity and a state.

• Generally with a counterpart on persistent storage support.

• Their state evolves as long as the application lives


Value Objects

Have no conceptual identity.

Can be designed as immutable

Can be shared between different entities


Services

A service represent an operation which is peculiar to the domain model

The interface is defined in term of other elements of the domain modelThe operation is stateless

Domain specific services belongs to the Domain layer


Modules

Modules are a way to partition the system to make it more manageable

Many languages implement them as packages

In DDD, packages should be divided according to the purpose instead of the

object type.Object type should result evident by the

Naming Convention


Aggregates

A cluster of associated objects that we treat as a unit for he purpose of data

changes.Guarantees integrity of the enclosed

Entities and Value ObjectA specific entity is selected as a root of

the aggregate


Aggregate Root contours

Aggregate roots and entities partition the domain into non overlapping regions.

Access to entities might only be performed through the corresponding root.

<<Aggregate Root>>A

<<Entity>>G

<<Entity>>F

<<Entity>>E

<<Entity>>B

<<Entity>>C

<<Aggregate Root>>D

Interestingly, this works pretty well to solve intricated double update problems or to define lazy loading strategies, and so on.


Factories

Correct creation of an instance of a complex object does not belong to the

object itself.Specific objects have the responsibility of creating the requested object instances


Repositories

Repositories provide data retrieval capabilities to the domain model

providing the illusion of an in-memory collection.

They abstract interaction with the underlying persistence layer offering services in terms of domain model

elements


Aggregate Object

Sometimes the responsibilty of the whole aggregate doesn’t really belong to the Aggregate Root entity.

Sometimes preserving integrity of the aggregate as a whole is a responsibility that deserves a role of its own

An Aggregate Object might coordinate invariants checking and state management between the different

entities of the aggregate


Domain Event

Sometimes our application is just tracking things that happen.

Those are normally modeled as Value Objects, but there’s no point in sharing, cause those events are

intrinsically unique.

a Domain Event represents an event which is meaningful in the domain.

There’s a similar concept in UML in Colour, which is called Moment-interval.


Putting it all together...Taken one by one, the patterns are not a

revolution.These patterns have been collected from

successful project, not invented.

Yet, taken together, they provide a scalable approach to manage complicated

domains.


Renewing building blocks

DDD is a technology-neutral paradigm, but since the original

enunciation the technical landscape evolved.

Some problems are no longer open, or the DDD solution suggested in the book


The good news

Many of the original shortcomings of mainstream architecture blueprints

have recently downsized.POJO based frameworks, ORM

frameworks might offer a mainstream solution to some of the

most common issues. Some problems are no longer open, or the DDD solution suggested in the book


Don’t fight your frameworks

DDD is a set of principles, rather than a reference implementation.

Choose the solution that fits best your development scenario, but keep track of

the trade-off cost

Some problems are no longer open, or the DDD solution suggested in the book might look obsolete nowadays. Factories are often managed by Spring or Hibernate

Strategic Domain Driven Design


Increased project size introduces new challenges to project management, architecture and domain

modeling as well


In a software development project, different finite resources have to be

managed and wisely allocated, to deliver the highest possible

value.This applies to time and budget,

but also to skills, talent, knowledge and expertise


Different domains are subjected to different

forces resulting in different speeds

and directions of the evolutions


Interlude: Biased history of a language


Many sources influenced the original model

... and the Romans were amongst then


reference implementations helped to establish a

standard


Large scale adoption of a standard bred

variations


A subset of the domain became a lingua franca allowing interoperability between different systemsThey were not originally meant to be part of the system


Despite all the efforts to produce extensive

documentation, single domains still evolve


Some domains do not adhere to standards





... and probably

never will


Still, new requirements and media might introduce changes also in consolidated domains


Large-scale DDD


Size matterslarger or more complicated domains cannot be managed in the same way:- purposes start to diverge- communication is less effective as team size

increases- efforts to maintain a coherent view might

outweigh its benefits


Partitioning- Larger domains can be partitioned in order

to maintain a coherent view, in a bounded context.

- The overall view must still be shared, as well as some key artifacts

- Splitting areas provides a more efficient way to evolve in a coherent context.

- Partitioning isn’t meant to be necessarily a phisical action. Sometimes it’s just accepting reality.


Context map

A model is valid in a specific context. Different context might need different version of the model, due

to specific purposes

Model in

context

Model in

context

Translation Map

So, we need a way to define contours and boundaries at a conceptual level.This will help us to have a snapshot of the exact shape of the system.


Shaping subdomains

Models must preserve their integrity.

A well defined domain can be defined by a well defined team

serving a specific goal.

A context is an environment (team, project, subproject) where a model can have its own integrity.


Prioritizing subdomains

Areas that provide the most significant value to the

application must be highlighted and isolated from the

surroundings

It takes significant skills and energy to build a good model. We can’t apply them equally in the large. We must find the sweet spot and focus where it matters more.


Core Domain

The portion of the application that provides the most value to the enterprise.

Focus on this portion of the system to provide the most significant value.

Preserve the domain from external influences


Generic Subdomain

A portion of the system which is not delivering specific value.

Sub optimal or tactical solutions are viable

opportunities:build, outsource, buy, reuse.

This portion of the application is needed, but making it perfect would not provide an signigicant increase in the value.The driver to determine value is always the business, so keep aligne with the business drivers for your domain.


Shared Kernel

An agreed subset of the system might be shared between different teams.

Strict coordination rules apply

Model in context

Model in context

Translation Map

Shared Kernel

Some portions of your application might be shared. Different teams might need to coordinate evolution of a shared portion of the system. However, coordination is expensive and it’s not always applicable.


Customer Supplier

Establish a customer-supplier relationship between the teams.

Development processes and planning will be correlated.

Share a translation map between the teams

There’s a formal agreement in place, meaning that both team have to agree on some practices and relationship between the two.This clearly has a cost, which has to be evaluated, within the organization.


Conformist

Passively adapt to another team’s model.

Implement a non-optimal solution in a subdomain, to

decrease communication costs between the team

If the Customer Supplier does not work... the battle could just be not worth the fight. This is a cheaper option from the organization’s point of view, but will also provide less value to the application.


Anticorruption Layer

A defense mechanism might be necessary to prevent leaking from one domain to another

one.Integrating different domains does not mean that

they serve the same purpose.

An anti-corruption layer isolates the translation and adaptation role in a specific layer

In some cases the borderline between two contexts needs to be guarded, to prevent concepts to leak in outside their boundaries.

The same concepts might have different representations in the two contexts. The ACL is where the translation happens, even in a “dirty way”.


Open Host

Sometimes, we know only one side of the boundary.

Integration might happen with an undefined number of external context.

We are not free anymore to define ad-hoc policies: an Open Host defines this type of

relationship

This is a fairly common situation in a SOA context. It can easily be tracked down to the English language example, meaning that once shared (as it is in Europe) a model isn’t free to evolve, because it turns into an integration level artifact.


Published Language

Opening a door to multiple context means giving up the freedom to evolve the underlying model.Sometimes, the language spoken at the border

becomes a model on its own.Sometimes, a standard language already exists on

a given domain, increasing integration possibilities.

SOA again gives us some examples: you can create a web service in seconds, exposing your domain objects. But once published you’re sometimes givin’up the possibility to evolve. A service exposed to an open channel/bus means that there is anothe model, living on the channel.


Separate ways

Sometimes, the cost of integration is higher than the integration benefits.

Short term, quick or simply unrelated solution does not necessarily belong to the big plan

Do we really need to integrate them anyway?


ReferencesDomain Driven Design

Eric Evans

Addison Wesley


ReferencesApply Domain Driven Design and Patterns

Jimmy Nilsson

Addison Wesley


Domain Driven Design discussion groups

• http://tech.groups.yahoo.com/group/domaindrivendesign/

• http://it.groups.yahoo.com/group/DDD-IT/

http://tech.groups.yahoo.com/group/domaindrivendesign/




http://it.groups.yahoo.com/group/DDD-IT/

http://it.groups.yahoo.com/group/DDD-IT/


Questions?