Date post: | 17-Oct-2014 |
Category: |
Technology |
View: | 5,723 times |
Download: | 1 times |
CopyrightAlbertoBrandolini2008
Taming complex domains with
Domain Driven Design
CopyrightAlbertoBrandolini2008
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]
CopyrightAlbertoBrandolini2008
What are we talking about?
The DDD book, by Eric Evans has been published in 2004, gaining increasing momentum since then.
CopyrightAlbertoBrandolini2008
...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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
DDD - what it is and why it matters
It’s a set of proven modeling techniques especially targeted to complex applications.
What it is and why does it matters
This is an approach that goes from small to large scale.
CopyrightAlbertoBrandolini2008
DDD - what it is and why it matters
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.
What it is and why does it matters
This is an approach that goes from small to large scale.
CopyrightAlbertoBrandolini2008
DDD - what it is and why it matters
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.It’s a set of patterns that support a clean and
coherent view of the domain model.
What it is and why does it matters
This is an approach that goes from small to large scale.
CopyrightAlbertoBrandolini2008
DDD - what it is and why it matters
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.It’s a set of patterns that support a clean and
coherent view of the domain model.It’s a set of pragmatic strategies allowing
applications to scale in size and complexity maintaining their integrity.
What it is and why does it matters
This is an approach that goes from small to large scale.
CopyrightAlbertoBrandolini2008
DDD - what it is and why it matters
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.It’s a set of patterns that support a clean and
coherent view of the domain model.It’s a set of pragmatic strategies allowing
applications to scale in size and complexity maintaining their integrity.
What it is and why does it matters
This is an approach that goes from small to large scale.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
The ecosystem
Agile Software Development practices should be in place, allowing
short iterations to gather users’ feedback from users
and domain experts.
The Model
CopyrightAlbertoBrandolini2008
CopyrightAlbertoBrandolini2008
CopyrightAlbertoBrandolini2008
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
The Mindset
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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...
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
Value Objects
Have no conceptual identity.
Can be designed as immutable
Can be shared between different entities
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
Increased project size introduces new challenges to project management, architecture and domain
modeling as well
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
Different domains are subjected to different
forces resulting in different speeds
and directions of the evolutions
CopyrightAlbertoBrandolini2008
Interlude: Biased history of a language
CopyrightAlbertoBrandolini2008
Many sources influenced the original model
... and the Romans were amongst then
CopyrightAlbertoBrandolini2008
reference implementations helped to establish a
standard
CopyrightAlbertoBrandolini2008
Large scale adoption of a standard bred
variations
CopyrightAlbertoBrandolini2008
A subset of the domain became a lingua franca allowing interoperability between different systemsThey were not originally meant to be part of the system
CopyrightAlbertoBrandolini2008
Despite all the efforts to produce extensive
documentation, single domains still evolve
CopyrightAlbertoBrandolini2008
Some domains do not adhere to standards
CopyrightAlbertoBrandolini2008
Some domains do not adhere to standards
CopyrightAlbertoBrandolini2008
Some domains do not adhere to standards
... and probably
never will
CopyrightAlbertoBrandolini2008
Still, new requirements and media might introduce changes also in consolidated domains
CopyrightAlbertoBrandolini2008
Large-scale DDD
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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”.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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.
CopyrightAlbertoBrandolini2008
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?
CopyrightAlbertoBrandolini2008
ReferencesDomain Driven Design
Eric Evans
Addison Wesley
CopyrightAlbertoBrandolini2008
ReferencesApply Domain Driven Design and Patterns
Jimmy Nilsson
Addison Wesley
CopyrightAlbertoBrandolini2008
Domain Driven Design discussion groups
• http://tech.groups.yahoo.com/group/domaindrivendesign/
• http://it.groups.yahoo.com/group/DDD-IT/
CopyrightAlbertoBrandolini2008
Questions?