Practicing DDD

Practicing Domain-Driven Design
Practical advice for teams implementing the development

philosophy of Domain-Driven Design. With code examples
in C# .NET.
Scott Millett
This book is for sale at http://leanpub.com/Practicing-DDD
This version was published on 2013-02-04
This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing
process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and
many iterations to get reader feedback, pivot until you have the right book and build traction once
you do.
2012 - 2013 Scott Millett
Tweet This Book!

Please help Scott Millett by spreading the word about this book on Twitter!
The suggested hashtag for this book is #Practicing-DDD.
Find out what other people are saying about the book by clicking on this link to search for this
hashtag on Twitter:
https://twitter.com/search/#Practicing-DDD
Contents
About The Author
Introduction
ii
Why You Should Read This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
Who Should Read This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
Domain-Driven Design In A Nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
A Problem Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
A Solution Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
How This Book Is Structured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
Other Books On Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Theory: Introduction To The Philosophy
The Need For Domain-Driven Design
1.1
A Philosophy Over A Framework Or Methodology . . . . . . . . . . . . . . . . . .
1.2
Writing Large-Scale Complex Business Software Is Hard . . . . . . . . . . . . . . .
Code Without Organisation Will Rot . . . . . . . . . . . . . . . . . . . . . . . . . .
Developing In Mud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding Your Problem Space
2.1
Knowledge Crunching : Finding The Model . . . . . . . . . . . . . . . . . . . . . .
What Is A Domain Model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gaining Domain Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Challenges With Upfront Design . . . . . . . . . . . . . . . . . . . . .
Team Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Techniques For Creating A Useful Model . . . . . . . . . . . . . . . . . . . . . . . .
13
Capture Use Cases Of The System . . . . . . . . . . . . . . . . . . . . . . .
13
Sketching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Defer The Naming Of Concepts In Your Model . . . . . . . . . . . . . . . .
14
CONTENTS
2.2
2.3
2.4
2.5
2.6
3
Powerful Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Rapid Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Look For Existing Models . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Domain Experts: Your Guide To Deeper Understanding In Your Problem Domain . .
16
Sit With Your Domain Experts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
Knowledge Distillation : Breaking Down Large Systems To Find What Is Core . . .
17
Subdomains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
Seeing The Wood In-spite Of The Trees . . . . . . . . . . . . . . . . . . . . . . . . .
18
Core Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Domain Vision Can Reveal What Is Core . . . . . . . . . . . . . . . . . . .
22
Generic Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Supporting Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
The Core Domain Doesnt Always Have To Be Perfect First Time . . . . . . . . . .
23
Subdomains Exist In The Problem Space . . . . . . . . . . . . . . . . . . . . . . . .
24
Model In Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
Without Context We Are Nothing . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Context Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Multiple Models In A Subdomain . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
Shifting Focus From The Project To The Product . . . . . . . . . . . . . . . . . . . .
28
Less Hast More Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
The Salient Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Speaking The Language Of Your Domain
30
3.1
The Language Of Domain Experts . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2
Collaborating On An Enhanced Language . . . . . . . . . . . . . . . . . . . . . . .
30
Enhancing The Language With Discovered Terms . . . . . . . . . . . . . . . . . . .
31
Working With Concrete Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.3
Teach Your Domain Experts To Focus On The Problem And Not Jump To A Solution 33
Using Features And Scenarios To Demonstrate Domain Scenarios . . . . . . . . . .
33
3.4
A Language Tied To A Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.5
35
CONTENTS
Shaping Your Solution Space
36
4.1
Retaining The Integrity Of Models In Subdomains . . . . . . . . . . . . . . . . . . .
36
The Challenges Of Maintaining A Single Model: Blurred Responsibility . . . . . . .
37
Bounded Contexts: Define A Boundary Of Responsibility Around A Model . . . . .
38
Implementing A Bounded Context . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
The Importance Of Bounded Contexts . . . . . . . . . . . . . . . . . . . . . . . . .
41
A Bounded Context Can Cover More Than One Subdomain . . . . . . . . . . . . .
42
More Than A Single Bounded Context Per Physical Deployment . . . . . . . . . . .
43
Sizing Your Models And Bounded Contexts . . . . . . . . . . . . . . . . . .
44
4.3
Architectural Patterns Apply To Bounded Contexts Not Systems . . . . . . . . . . .
45
4.4
Understanding The Relationships Between Bounded Contexts . . . . . . . . . . . .
46
Context Maps Clearly Show Business Process . . . . . . . . . . . . . . . . . . . . .
47
Bounded Contexts Work Together To Solve Business Problems . . . . . . . . . . . .
47
Integration Between Bounded Contexts . . . . . . . . . . . . . . . . . . . . . . . .
49
Modules (aka .Net Namespaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
Anti Corruption Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
Introducing Bounded Contexts Into Legacy Code . . . . . . . . . . . . . . .
51
Shared Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
Open Host Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Patterns For Team Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Customer-Supplier (Upstream/Downstream) . . . . . . . . . . . . . . . . . . . . . .
56
Conformist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
Partnership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
57
4.2
4.5
4.6
4.7
5
Complex Core Domains Should Be Based On A Model
58
5.1
The Domain Model: Expressing The Model In Code . . . . . . . . . . . . . . . . . .
58
Model Only What Is Relevant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
A Clean Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
Persistence Ignorance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
CONTENTS
Dont Model Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
A Useful Abstraction On Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
Reveal The Behaviour Of The Domain . . . . . . . . . . . . . . . . . . . . . . . . .
62
The Code Model Is The Only Truth . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
Hands On Modellers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
Tactical Patterns: The Building Blocks Of Model Driven Design . . . . . . . . . . .
63
Model Structure Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
Value Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Aggregates and Aggregate Roots . . . . . . . . . . . . . . . . . . . . . . . .
71
Domain Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Domain Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Life Cycle Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Factories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
Application Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
Infrastructure Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.3
Presentation Concerns: The Command Vs Query Paradox . . . . . . . . . . . . . .
83
5.4
86
5.2
Refactor for Deeper Design Insights
88
6.1
Non Technical Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
6.2
Making The Implicit Explicit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
Give Things A Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
6.3
Challenge Your Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
6.4
Supple Code Aids Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
6.5
92
What DDD is not
7.1
93
Patterns For Understanding The Problem Space Are Useful On All Projects, ModelDriven Design May Not Be . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
Code Is A Product Of DDD Not The Process . . . . . . . . . . . . . . . . . . . . . .
93
CONTENTS
7.2
DDD Is Not For The Faint Hearted . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
7.3
Ask Yourself: Is It Worth This Extra Complexity? . . . . . . . . . . . . . . . . . . .
95
Beware The Anemic Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . .
95
Not A Solution To Every Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
95
7.4
II The Practice: Coding The Strategic And Tactical Patterns Of DDD
97
Strategic Patterns of Domain-Driven Design
98
The Building Blocks of Domain-Driven Design
99
10 Domain-Driven Design Best Practices
100
III Case Study: Putting Theory And Coding Patterns Into Practice
101
11 A Modelling Example
102
11.1 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Appendix
103
Version History
104
About The Author

Scott Millett is an enterprise software architect working in London for Wiggle.co.uk, an e-commerce
company specializing in cycle and triathlete sports. He has been working with .NET since version
1.0 and was awarded the ASP.NET MVP in 2010 and again in 2011. When not writing about or
working with .NET he can be found relaxing and enjoying the music at Glastonbury and many of
the major music festivals in the UK during the summer. If you would like to talk to Scott about
the book, anything .NET, or the British music festival scene, feel free to write to him by email at
scott@elbandit.co.uk, or by giving him a tweet @ScottMillett.
Scotts Books:
Real World .NET, C#, and Silverlight: Indispensible Experiences from 15 MVPs (Chapter 13
BDD) (Wrox, 2011)
Pro Agile .NET Development with SCRUM (Apress, 2011)
Professional ASP.NET Design Patterns (Wrox, 2010)
Professional Enterprise .NET (Wrox, 2009)
NHibernate with ASP.NET Problem Design Solution (Wrox, 2009)
Introduction
Why You Should Read This Book
Writing software is easy, sorry writing greenfield software is easy. When it comes to modifiying
code written by other developers or code you wrote six months ago, it can be a bit of a bore at
best and a nightmare at worst. The software works but you arent sure exactly how. It contains all
the right frameworks, patterns and has been created using an agile approach, yet introducing new
features into the code base is harder than it should be. Even business experts are of no use as the
code bears no resemblance to the language they use. Working on such systems becomes a chore
leaving developers frustrated and devoid of any coding pleasure.
Domain-Driven Design (DDD) is a process that aligns your code with the reality of your problem
domain. As your product evolves, adding new features is as easy as it was in the good old days
of greenfield development. Where DDD understands the need for software patterns, principles,
methodologies and frameworks, it values developers and domain experts working together to
understand domain concepts, policies and logic equally. With a greater knowledge of the problem
domain, and a synergy with the business, developers are more likely to build software that is more
readable and easier to adapt for future enhancement.
Following the DDD philosophy will give developers the knowledge and skills they need to tackle
large or complex business systems in an effective manner. Future enchancement requests wont be
met with an air of dread and developers will no longer have stigma attached to the legacy application.
In fact the term legacy will be recategorised in a developers mind as meaning; A system that
continues to give value for the business.
Who Should Read This Book

This short book introduces the main themes behind Domain-Driven Design (DDD), its practices
and principles along with my experiences and interpretation of the philosophy. It is intended to
be used as a learning aid for those interested in or are starting out with the philosophy. It is not
a replacement for Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric
Evans (Addison-Wesley Professional, 2003). Instead it takes the concepts introduced by Evans and
distils them into simple straightforward prose, with practical examples in order for any developer
to get up to speed with the philosophy before going on to study the subject in more depth.
This book is based on my experiences with the subject matter so you may not always agree with it
if you are a seasoned DDD practitioner, but I do hope you still get something out of it. Either way
please send me feedback on the book and let me know if you need any area explored in more detail
or if I have not succeeded in my goal of explaining concepts simply and concisely.
I look forward to receiving your feedback - scott@elbandit.co.uk.
ii
iii
Introduction
Domain-Driven Design In A Nutshell

A Problem Space
Before you can develop a solution you must understand the problem. Domain-Driven Design
emphasises the need to focus on the business problem domain; its terminology, the core reasons
behind why the software is being developed and what success means to the business. The need for
the development team to value domain knowledge just as much as technical expertise is vital to gain
a deeper insight of the problem domain.
The figure below shows a high-level overview of the problem space of Domain-Driven Design that
will be introduced in the first part of this book.
A blueprint of the problem space of Domain-Driven Design.
A Solution Space
With a sound understanding of the problem domain strategic patterns of DDD can help you to
implement a technical solution in synergy with the problem space. Patterns enable core parts of your
system that are crucial to the success of the product to be protected from the generic areas. Isolating
integral components allows them to be modified without having a rippling effect throughout the
system.
iv
Introduction
Core parts of your product that are sufficiently complex or will frequently change should be based
on a model. The tactical patterns of DDD along with Model-Driven Design will help you to create
a model. A model that is in synergy with the problem domain will enable your software to be
adaptable and understood by other developers and business experts.
The figure below shows a high-level overview of the solution space of Domain-Driven Design that
will be introduced in the first part of this book.
A blueprint of the solution space of Domain-Driven Design.
How This Book Is Structured

The first part of this book is an introduction on Domain-Driven Design. Its heavy on the prose and
light on the code samples. If you already have a good grounding in the philosophy then you can
skip this part and go straight to the code in part II.
Part II puts the theory of the strategic and tactical patterns of DDD into practice. I show you
implementations of the patterns contained within Erics book along with some best practices to
aid you with Model-Driven Design.
Part III is an end-to-end case study designed to show you how to put the practices of DDD together
in order to design and build a complex system.
Introduction
Part I: The Theory: Introduction To The Philosophy

The opening section of the book introduces you to the philosophy of DDD. You will learn why
DDD is needed when dealing with the creation of large complex systems and how it can help
you to avoid an unmanageable code base.
The importance of the collaboration with Domain Experts to gain domain knowledge is
discussed next. Domain knowledge will enable you to understand the most important areas
of the application you are creating and where to spend the most time and effort.
The benefit of creating a shared Ubiquitous Language is then explored. The idea of a shared
language is core to DDD and underpins the philosophy. A language describing the terms and
concepts of the domain, which is created by both the development team and the business
experts, is vital to aid communication on complex systems
Strategic coding patterns designed to protect the integrity of core parts of the domain are
presented after knowledge of the domain is gained along with patterns to aid team working.
Tactical patterns for implementing the Model-Driven Design methodology for complex core
areas of your application are covered in depth.
The last section of part I describes when not to use Domain-Driven Design, and why its
just as important as knowing how to implement it. Simple systems require straight forward
solutions. The end of this part looks at why applying DDD to simple problems can lead to
overdesigned systems and needless complexity.
Part II The Practice: Coding The Strategic And Tactical Patterns Of DDD
(TBC) Strategic Patterns of Domain-Driven Design
Details on the options open for architecting Bounded Contexts.
Code examples detailing how to integrate with legacy applications.
Techniques for communicating across Bounded Contexts
(TBC) The Building Blocks of Domain-Driven Design
Implementation patterns for the building blocks of DDD.
(TBC) Domain-Driven Design Best Practices
Best practices for development.
Part III Case Study: Putting Theory And Coding Patterns Into Practice
(TBC) A Modelling Example
Working through the creation of an application based with a complex domain to
showcase all the practices of DDD.
Other Books On Domain-Driven Design

Evans original text on Domain-Driven Design:
Introduction
vi
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

(Addison-Wesley Professional, 2003)
Other good books on Domain-Driven Design are:
Applying Domain-Driven Design and Patterns: Using .Net by Jimmy Nilsson (Addison
Wesley, 2006)
Implementing Domain-Driven Design by Vaughn Vernon (Addison Wesley, 2013)
Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce
(Addison Wesley, 2009)
Specification by Example: How Successful Teams Deliver the Right Software by Gojko Adzic
(Manning Publications, 2011)
Websites and groups on Domain-Driven Design:
http://groups.yahoo.com/group/domaindrivendesign
http://domaindrivendesign.org
I The Theory: Introduction To The

Philosophy
Whats in this part?
Introduction to the philosophy of Domain-Driven Design

The problem of blurred responsibilities in code resulting in the big ball of mud
Collaborating with domain experts to gain domain knowledge
Understanding the importance of identifying the core, supporting and generic domains in
system under development
The benefit of creating a shared ubiquitous Language in order to describe the terms and
concepts in the domain
Protecting the integrity of core parts of the domain
Driving development of complex core domains with Model-Driven Design
When not to use Domain-Driven Design
1 The Need For Domain-Driven Design

It is not the strongest of the species that survives, nor the most intelligent that
survives. It is the one that is the most adaptable to change. Charles Darwin
Domain-Driven Design (DDD) is a development philosophy defined by Eric Evans in his seminal
work Domain-driven design: tackling complexity in the heart of software (Addison-Wesley Professional, 2003). DDD prescribes a set of principles and practices aimed at refocusing efforts along
with investment around the most critical and key parts of large-scale business software; namely
the business logic, concepts, terminology, workflows and processes. The benefit of practicing DDD
allows the software to be quickly adapted to support change in the business and deliver value to the
areas that are most important.
The three main practices that underpin the philosophy are:
Understanding which part of a large system is fundamentally important to a business,
i.e. what is considered core to its success, what will set this system apart from others in
the same market, and what gives it the edge; put another way, what part of the system
does your business consider its competitive advantage.
Capturing concepts, communicating and writing code using a shared language based on
the domain you are working within.
Basing the core area of the application on a model of the business problem domain using
the tactical patterns of DDD and following a model-driven design. Whilst employ ing
strategic patterns of DDD to protect the integrity of the core area and subdomains of
the system.
1.1 A Philosophy Over A Framework Or Methodology

DDD is not a strict methodology nor is it a framework that you can leverage to build applications
upon. Instead it is, in its purest form, a development mind shift for teams writing complex or
frequently changing large-scale business software. Focus, investment and effort are placed deeply
within the core business domain with technical considerations playing a mere supporting
role. DDD promotes collaboration, evolution and experimentation above everything else in order
to develop a useful model of the business domain which is placed at the heart of the software.
What I love most about DDD is that its not an inhibitive methodology or framework; Its a
collaboration philosophy focused on delivery.
Strategic patterns of DDD can help you to identify and isolate the parts of the system that are defined
as core to the success of the software. These patterns will enable you to retain the integrity of these
areas. If the core parts of your business software are sufficiently complex then tactical patterns of
DDD can help you to create software of a high quality by basing the core domains (the parts a system
2
that will give you the most value) on an abstract model that reflects the real business subdomain.
This model will enable the core parts of the system to be flexible enough to change when critical
parts of the business change.
What is a Problem Domain?
A problem domain refers to the subject area that you are building software for. DDD stresses
the need to focus on the domain above anything else when working on creating software
for large-scale and complex business systems. Experts in the problem domain work with
the development team to focus on the areas of the domain that are useful to be able to
produce valuable software. For example when writing software for the health industry to
record patient treatment it is not important to learn to become a doctor. What is important
to understand is the terminology of the health industry, how different departments view
patients and care, what information doctors gather and what they do with it.
.
1.2 Writing Large-Scale Complex Business Software Is

Hard
It doesnt take a lot of skill to get a program to work. The skill comes in when
you have to keep it working. Robert C. Martin @unclebobmartin
The challenge of writing and enhancing software for large-scale complex systems is not just about
technical considerations. In fact for complex domains the technical concerns could be very simple.
The development team should focus as much enegery and effort on the domain logic as they do
on the technical aspects. Teams should understand why theyre producing the software and what
it means for the software to be successful to the business. It is the appreciation for the business
intent that will enable the development team to identify and invest their time in the most
important parts of the system. As the business evolves, so in turn must the software; it needs to
be adaptable. Investment in the quality of code in the key areas of the system will help it to change
easier with the business. If key areas of the software are not in synergy with business domain then,
over time, it will rot and turn into a big ball of mud. Resulting in software which is hard to maintain.
Before Creating A Solution You Must Understand The Problem

Software projects fail when we dont understand the business model. Typing is not the
bottleneck for delivering a product; coding is the easy part of development. Understanding,
analysis and discovering a solution to a problem is the hard part. The greater you understand
your business domain the better equipped you will be when you are trying to solve problems
within it.
.
Code Without Organisation Will Rot

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-andbaling-wire, spaghetti-code jungle. Brian Foote and Joseph Yoder
By far the most popular software architectural design pattern for business applications is the Big Ball
of Mud (BBoM) pattern. BBoM, as defined by Brian Foote and Joseph Yoder, describes an application
that appears to have no distinguishable architecture (think big bowl of spaghetti versus a dish of
layered lasagne). The issue with allowing software to dissolve into a BBoM becomes apparent when
routine changes in workflow and small feature enhancements become a challenge to implement
due to the difficulties in reading and understanding the existing code base. In his book, Eric Evans
describes such systems as containing code that does something useful but without explaining how.
We typically find that the initial incarnation of a system that resembles BBoM was fast to
produce and a well-rounded success, however because there was little focus on business need,
subsequent enhancements are troublesome. The code base lacks the required synergy with the
business behaviour to make change manageable.
Developing In Mud
Continuing to persist with an architectural spaghetti-like pattern can lead to a sluggish pace of
feature enhancement. When newer versions of the product are released often they can be buggy
due to the unintelligible mess of the code base that developers have to deal with. Over time the
development team increasingly complains about the difficulty of working in such a mess. Even if
resource is added to the project, velocity cannot be increased to a level that satisfies the business.
In the end, exacerbated by the situation, the request for the dreaded application rewrite is granted.
Without due care and consideration however even the greenfield project can often fall fowl of the
same issues that created the original BBofM. This entire experience can be frustrating for the business
that saw a great return on investment in terms of features and speed of delivery at the beginning
but over time, even with additional investment in resource, did not see the sustained evolution of
the product to meet the needs of the business.
The Ticking Technical Debt Time bomb

Technical debt is the name given to poorly created and hastily written code. Technical debt
is a result of quick and dirty changes instead of a considered and clean approach to software
design. Technical debt is similar to financial debt in that if you do not pay it back quickly
you will incur greater costs later when you try and deal with it. The problem with technical
debt is that it makes future changes to the software very difficult as the code is constructed
in an unorganised manner. Sometimes it is a pragmatic choice to incur some technical debt
in order to hit a deadline. However it is important that after the deadline is met, and if the
software will be continued to be invested in, that the technical debt be paid back in the form
of refactoring.
.
What is Refactoring?
Refactoring is the redesign of a softwares structure without altering its functionality. The
purpose of refactoring is to make the software design easier to read and easier to change,
as developers spend more time reading code than writing it. As teams iterate through the
creation of a product they learn more about the domain, and this knowledge needs to be
transferred into code. Lots of small refactorings enable deeper insight into the problem
domain and will enable other developers to understand and modify the software with greater
ease in the future. Unit and integration tests support refactoring by enabling developers to
alter the design of software with the confidence that they wont break existing functionality.
.
2 Understanding Your Problem Space

As you read the explanations of these terms, here and in the book [Evans, DDD],
remember that all of these terms are first about how to organise the concepts that
are behind the design. From that follow techniques for organising the physical
implementation of those concepts. Eric Evans, DDD Forum
So what is required to tackle the creation of a complex application? How can we ensure we are
building solid systems that meet the wishes of the business? That will work with us in the future,
rather than working against us when the business needs to quickly alter a process or policy? As the
enablers we need to refocus our efforts when creating and designing software. We need to focus on
the problem that the business is trying to solve with the application, and not the next fashionable
development practice or shiny new framework. We need a codebase that contains a model of the
domain in synergy with the business. Constantly evolving as the business changes. We need
to align ourselves with the vision of the software. Clearly understanding what is core to the
success of the application.
The aim of this chapter is to show you how you can align the development team to the intent and
wishes of the business as you begin to capture requirements and break down the problem domain.
The figure below shows the areas of the DDD that relate to understanding the problem space.
http://tech.groups.yahoo.com/group/domaindrivendesign/message/1504
The problem space.
2.1 Knowledge Crunching : Finding The Model

If you cant explain it in simple terms, you dont know it well enough. Einstein
Knowledge crunching is the art of soaking up information about the problem domain whilst
having the ability to sift out whats not important in order to create an effective model of
the domain, otherwise known as a domain model. Knowledge gathering occurs on whiteboards,
working through examples with business experts and generally brainstorming together. It is the
quest to discover and agree on a shared understanding of the problem domain.
What Is A Domain Model?

The domain model is at the centre of Domain-Driven Design. It is expressed as a code implementation which represents a view, not the reality, of the problem domain. Its usefulness comes in its
ability to represent complex logic and polices in the domain in order to solve business problems. It
also exists in a more abstract space, in the language the team speak and the diagrams they sketch.
The model is built from the collaboration between the development team and business experts.
The model contains only what is relevant to solve problems in the context of the application being
created. It needs to constantly evolve with the business in order to keep itself useful and valid.
A domain model can be represented in UML or code as shown in the figure below.
A domain model in code and UML.
So where do we start when trying to create a domain model? How do we as developers get a greater
understanding of the problem domain we are creating software for?
Gaining Domain Knowledge

the key to expert performance in many fields is domain knowledge rather than
intelligence. Don Reinertsen
Domain knowledge is key. Teams working in a business with complex processes and logic need
to immerse themselves in the problem domain, and, like a sponge, absorb all the relevant domain
knowledge. This insight will enable teams to create a model at the heart of their applications code
base that can fulfil the wishes of the business.
The Challenges With Upfront Design

Writing code is not the problem.
Historically the capturing of requirements for software systems was seen as an activity that could
occur long before coding was due to start. Business experts would talk to business analysts, who in
turn would talk to architects who would produce an analysis model based on all of the information
from the problem domain. This analysis model would then be handed over to the developers, along
with wireframes and workflow diagrams in order for them to build the system.
What Is An Analysis Model?
An analysis model is a collection of artefacts that describe the model of a system. These
artefacts can be in the form of UML such as class diagrams and interaction sequence
diagrams. The analysis model exists to understand the problem domain; it is not a blueprint
for the technical implementation.
.
As developers start to implement the analysis model in code they would often find a mismatch
between the high-level artefacts produced by architects and the reality of building the system.
However at this stage there is often no feedback loop for developers to talk to the business and
architects in order for the analysis model to be updated and their discoveries to be reflected.
Instead the developers diverge from the analysis model and their implementation often overlooks
important and descriptive domain terms and concepts that would have provided deeper insight and
understanding of the domain.
As the development team further evolves away from the analysis model it becomes less and less
useful. Crucial insight into the model is lost as the development team focus on abstracting technical
concerns instead of business concepts. In the end the job gets done but the code bares no reflection
to the original analysis model. The business still believe their analysis models are correct. They
are unaware of the alterations within the code model required to fulfil the wishes of the business
application.
The figure below shows how the analysis and code models can diverge from each other if the
development team are not involved in domain knowledge crunching.
10
The problems with upfront design.
The reason why this is a problem is revealed when later enhancements to the codebase are difficult to
implement. The difficulties are due to the business experts and developers having different models
of the business. The code doesnt have a synergy with the business processes and is not rich in
domain knowledge.
Team Modelling
DDD suggests a more collaborative method of capturing system requirements and understanding
existing workflow. Emphasis is placed on the entire team together with business experts and
architects (as long as they code) having discussions around the problem space. Discussions can
include any documentation or legacy code that is related to the system in question. The idea behind
the collaborative knowledge crunching sessions is for the developers, testers, business analyst,
architects and business experts to work as a single unified team. This enables the developers
and testers to learn about the meaning behind domain terms and understand complex logic in
the problem area. It will also enable business experts to experience the modelling techniques
employed. With an understanding of modelling, business experts, will themselves, be able to
model and validate designs with the development team.
11
The sharing of information enables business experts to contribute to the software design as well
as providing a deeper insight and understanding of the domain to the development team. After a
period of time developers, and business experts will discover the relevant information to build an
initial model of problem domain. This initial model is put to test by using domain scenarios; real
problems of the domain to validate its usefulness. Modelling out loud, using the terms and language
of the model can also help to validate early designs.
The important aspect of modelling together is the constant feedback the development team get from
the business experts. This leads to the discovery of important concepts and also allows the team to
understand what is not important and can be excluded from the model. Breakthroughs in sessions
are manifested as simple abstractions that clarify complex domain concepts which lead to a
more expressive model.
The model is then expressed in code and the team, along with business experts can gain fast feedback
with early versions of software. Feedback in turn fuels deeper insight which can be reflected in the
code and analysis models, as highlighted in the figure below.
The code model and the analysis model are kept in synergy.
During each iteration the development team may come across parts of the model that they thought
were useful and could solve a problem, but during implementation they had to change. This
knowledge is fed back to the business experts for clarification and to refine their own understanding
12
of the problem domain. In this process the code model and analysis model are one and a change in
one will result in a change to the other
The figure below shows how the analysis and code model are in synergy and evolve as one during
the creation of a product.
Team modelling.
The Model DDD Cares About

Domain-Driven Design doesnt advocate the removal of the analysis model. Far from it
as there is much value to be gained from a model that describes the system. Instead
DDD emphasises the need to keep the code model; the implementation, in close synergy
with the analysis model; the design. The utopia is a single model that has value in both
implementation and design. To achieve this it is crucial to keep the code model clean of
technical concerns and focused on the domain. In turn it is also important to have an analysis
model that can be implemented; not too abstract or high-level to be of any use.
.
13
Modellers Block?
Wake yourself up. Brainstorm in code by capturing business requirements as classes and
methods. Model on the whiteboard, on paper, with your colleagues or even your wife. Warm
your brain up by doing something, anything, and the design will eventually bubble up in
your consciousness. If that doesnt work perhaps ideas appear to you during times of quiet
contemplation, and there is no better time for that then when getting the teas in for the team.
Either way, invest in your problem by giving yourself time to think.
.
Techniques For Creating A Useful Model

All of the most creative professionals played with the problem longer before they
attempted to resolve it John Cleese
Creating a useful model is a collaborative experience however business users can also find it tiring
and can deem it to be unproductive. Business users are busy and have a lot to do. In order to make
your knowledge crunching session fun and interactive you can introduce some facilitation games to
engage with your business users.
Capture Use Cases Of The System

The best place to start when trying to understand a new domain is by mapping out use cases. A use
case lists the steps required to achieve a goal, including the interactions between users and systems.
Work with business users to understand what users do with the current system, be it a paper based
process or computerised. Be careful to listen out for domain termingology as this will form the
start of your shared language for describing and communicating the problem domain. Remember,
capture a process map of reality, understand the workflow as it is, dont try and jump to a solution
too quickly before you truely appreciate the problem.
Sketching
UML is a wonderfully useful language that can be used to communicate complex systems in an
understandable manner with little or no technical expertise. Therefore its a good choice to capture
the initial analysis model. However during knowledge crunching sessions a model is a fluid entity
and will be changing at a rapid rate. Therefore dont try and use elaborate packages such as Visio
or Rational Rose to capture a moving model. Instead sketch out the model on the white board. You
will be less precious about a sketch that took you minutes to draw than a diagram in Visio that took
you most of the morning. If you must write up your knowledge crunching sessions do it at the end
when you know the most about the problem domain.
14
Team modelling on a whiteboard.
Defer The Naming Of Concepts In Your Model

Naming is very important when modelling a domain. However premature naming can sometimes
be a problem when we discover through further knowledge crunching that concepts turnout to be
different to what we first understood them to be. The issue is the association with the word that
was chosen as the original name, and the way it shapes our thinking. Grey Young suggests that
we make up words for areas of the model we are not sure about using gibberish . I tend to favour
using colours, but the idea is the same. Instead of giving areas or concepts of the model real names
use gibberish until you have understood all the responsibilities, behaviour and data of a concern.
Deferring the naming of concepts in your model will go a long way to helping you avoid modelling
reality.
Also look out for overloaded terms. The types of names that you want to avoid are XXXXService
or XXXXManager. If you find yourself post pending service or manager to a concept think more
creatively, striving for real intent behind a name. When you feel you have really understood a part
of the model you will be in a better place to give it a sensible and meaningful name.
Powerful Questions
Powerful questions are key to good analysis sessions. Greg Young
What does good look like? What is the success criteria of this product? What will make it a
worthwhile endeavour? What is the business trying to achieve? The questions you ask during
knowledge crunching sessions will go a long way to revealing a greater understanding of the
importance of a the product you are building and the intent behind it.
Here are some examples to get your domain expert talking and revealing some deeper insight into
the domain:
http://codebetter.com/gregyoung/2012/02/28/the-gibberish-game-4/
15
Where does the need of this system come from?

How will this system give value to the business?
What would happen is this system wasnt built?
Greg Young has a great blog post on powerful questions with comments offering many more good
examples of questions that can unlock domain knowledge.
Rapid Prototyping
Favour rapid prototyping during knowledge crunching sessions. Business users like nothing more
than screen mock-ups, as it reveals so much more about the intent they have behind a product. Users
understand UI, they can interact with it and act out workflows clearly.
Another form of rapid prototyping is to capture requirements in code. Greg Young calls this code
as analysis. Again business users will love the fact that you are writing and creating before their
eyes. Starting to code will help focus analysis sessions. Starting to implement abstract ideas from
knowledge crunching will enable you to validate your design. It also helps to avoid you only thinking
abstractly which can lead to analysis paralysis.
Coding quickly helps create your powerful questions. Helps find missing use cases. Use the code to
identify and solve the problems. After an hour or so of talking see if you can create a code model of
your brainstorming. I often find creating code quickly helps to cement domain concepts and speeds
up knowledge crunching as the team is deeply engrossed in learning about the domain.
Remember only create a code model of what is relevant and within the specific context to solve a
given problem; you cant effectively model the entire domain. Think small and model around rules
then build up. Most importantly remember that you are writing throw away code, dont stop at the
first useful model, and dont get too attached to your first good idea.
Look For Existing Models

Sometimes you dont need to reinvent the wheel. If you are working in a domain that has been
around for a long time such as a financial institution you can bet that it probably follows a known
model. You wont have time to become an expert in your problem domain so seek out information
that teaches your more about the domain. Analysis Patterns: Reusable Object Models by Martin
Fowler (Addison-Wesley, 1996) presents many common models in a variety of domains that you can
use as a starting point in discussions.
Models of the problem domain could already exist in the organisation. Ask for existing process
maps, workflow diagrams to help you understand the domain at a deeper level. Create a knowledge
base like a wiki with terms and definitions to share with the team. Remember you are only as good
as your weakest developer, this applies to domain knowledge as much as technical expertise.
http://goodenoughsoftware.net/2012/02/29/powerful-questions/
http://skillsmatter.com/podcast/open-source-dot-net/mystery-ddd
http://sourcemaking.com/antipatterns/analysis-paralysis
16
Try, Try And Try Again

You wont get a useful model on the first attempt; you might not even get one on the second
or third attempts. Dont be afraid of experimentation. Get used to ripping up designs and
starting again. Remember there is not a correct model, only a model that is useful for the
current context and set of problems you are facing.
.
2.2 Domain Experts: Your Guide To Deeper

Understanding In Your Problem Domain
The collaboration between the business customer and the development team is an essential aspect of
DDD and one that is crucial to the success of a product under development. However it is important
to seek out those who are experts in the domain you are working in, and who can offer you deeper
insight into the problem area. DDD refers to these subject matter experts as domain experts. The
domain experts are the people that deeply understand the business domain from its policies
and workflows, to its nuisances and idiosyncrasies. They are the experts within the business
of the domain, they will rarely, if ever, have the title Domain Expert. Instead look for the
product owners, users and anyone who has a great grasp and understanding for the domain
you are working in regardless of title.
Make The Most Of Your Domain Expert, You Never Know When She Will Be Gone
Utilise the time spent with your domain expert, dont just ask them to produce sets of
requirements or validate ones that you have produced. Actively engage with domain
experts in knowledge distilling sessions, whiteboard with them, experiment and show
how you have a desire to learn more about the domain you are producing software for.
A domain experts time will be precious, meeting them halfway and showing a genuine
interest will display to the domain expert that there is value in sharing knowledge.
.
Sit With Your Domain Experts

To enable the high level of collaboration it is recommended to co-locate the development team
with domain experts who will be on hand to answer questions and participate during analysis at
impromptu corridor or tea station meetings; something that is lost when the only communication
is restricted to weekly project meetings. The collaboration is such an essential part of DDD that
17
without it a lot of the design breakthroughs would not happen. It is this deeper design insight
that makes the software useful and able to adapt as and when the business processes change.
If its not possible to sit with your domain expert then join her for lunch. Spend as much time as you
can with her, learn as much as possible. You will never gain an insight into a domain from weekly
project meetings. You must eat, sleep and breathe it. Read around the subject; immerse yourself in
it. You will produce better software.
Be Careful What Youre Asked For
Be wary of customers asking for enhancements to existing software as they will often give
you requirements that are based on the constraints of the current systems rather than what
they really desire. Ask yourself how often you have engaged with a user to really find
the motivation behind a requirement. Have you understood the why behind the what?
Once you share and understand the real needs of a customer you can often present a better
solution. Customers are usually met by surprise when you engage them like this, quickly
followed by the classic line: Oh really I didnt know you could do that? Remember, you
are the enabler, dont blindly follow the users requirements, business users may not be able
to write effective features and express goals. You must share and understand the underlying
vision and be aware of what the business is trying to achieve in order to offer real business
value.
.
2.3 Knowledge Distillation : Breaking Down Large

Systems To Find What Is Core
Much of the essence of building a program is in fact the debugging of the
specification Fred Brooks
As you are modelling a system you may start to feel its getting a little large. Signs such as the
inability to fit a UML diagram on a single six foot wide whiteboard mean you need to break up
your model. When building any large system you wont be able to create a single domain model
that adequately covers it. Terms will mean different things in different parts of you domain and too
large of a model will be incomprehensible.
You need to understand that there will be some parts of the application that are more important than
others. Some parts will need more attention and investment than others to make the application a
success. During knowledge crunching with domain experts its important to reduce the noise of
whats unimportant to enable you to focus on what is important; use distillation to reveal the core
areas of the system. Deeply model what is core and focus on what will make a difference.
18
Subdomains
Large models can be broken down into subdomains in order to focus on specific areas of the domain
to create more focused smaller models. Many of these subdomains will be generic to any enterprise
business software such as reporting and notification needs. These subdomains, which do not define
the application are referred to as generic domains. The areas that distinguish your companys unique
product offering from a rivals and defines what gives it a competitive edge in the market are known
as your core domains. The core domains are the reason why you are writing this software yourself.
The remainder of the subdomains that make up a large-scale applications are known as supporting
domains.
One Model To Rule Them All?
It may seem sensible to model the entire problem domain using an enterprise model.
However this can be problematic due to the fact that it will need to cater for all the needs
of your domain. This will render the model too complex or overly generic and devoid of
any meaningful behaviour. If you have large systems it is far better and more manageable
to break down the problem space into smaller more focused models that can be tied to a
specific context.
.
Seeing The Wood In-spite Of The Trees

Take the domain model of an e-commerce application. There are many different components that
make up the large overall system. Some parts will be found in any e-commerce system, however
some will be unique to your company. These parts will define the software and will be the
fundamental reasons of why you are building rather than buying.
The figure below shows the large domain model of an e-commerce application.
19
The domain of e-commerce.
The figure below shows how the domain model of an e-commerce application can be distilled into
subdomains.
20
The domain of e-commerce distilled into subdomains.
The distillation of knowledge after sessions with domain experts should reveal whats unique and
important about the application you are about to create. The subdomains can be separated into core,
generic and supporting domains as shown in the figure below.
21
The distilled domain of e-commerce sorted into core, generic and supporting domains.
In order to know where to invest the most effort and quality its crucial to understand where the core
domains are as these are key to making the software successful. This knowledge is distilled from
knowledge crunching sessions working in collaboration with domain experts to understand
whats the most important aspect of the product under development.
Core Domains
To understand whats core to the product that your business is asking you to develop you need to
ask yourself: What are the parts of the product that will make it a success? Why are these parts of
the system important? And why cant they be bought off the shelf? In other words, what makes
your system worth building?
The core parts of the system represent the fundamental competitive advantage that your
company can gain through the delivery of this software. Whats core is not always obvious.
If the generic domains should be bought in and have little development, then the core domain is the
polar opposite. The core domains will require your best developers, your commandos if you will.
22
The core domains may not make up the lions share of your companys technology but they will
require the most investment.
What is core will certainly change over time. If you are successful competitors will mimic, so the
core domain must evolve in order to set your business apart from the rest and keep it ahead of the
game. Its vital that the development team take this on board and ensure they are in synergy with
the values of the software and the business.
The Core Domain of Pottermore.com
Pottermore.com is the only place on the web were you can buy digital copies of the Harry
Potter books. Like any e-commerce site it has the ability to browse products, store products in
a basket and checkout. The core domain of the Pottermore site is not what the customer sees,
but rather what they do not. Pottermore books arent DRM-locked , they are watermarked.
This invisible watermark allows the books that are purchased to be tracked if they should
be hosted illegally on the web. The core domain of the Pottermore system is the subdomain
that enables this watermarking technology to deter illegal distribution of a book without
infringing on the customer e.g. she can copy the book to any other her devices. This is
whats most important to the business, what sets it apart from other ebook sellers and what
ensures the system was built rather than being sold on iTunes or other ebook sellers.
http://www.futurebook.net/content/pottermore-finally-delivers-harry-potter-e-books-arrive.
Domain Vision Can Reveal What Is Core

Before embarking on any product engagement always ask for a project overview. In any large
organisation the process of project inception starts long before the development team get involved.
Often there will be a small paper on why the company wants to build the software for this initiative
over another. This paper often holds the key to the core domain. The paper is a justification on why
writing the software is a good idea, study this and a pick out what is important. Make it explicit
by writing the salient points on the whiteboard so all the team understand why they are writing
the software. The Domain vision statement will reveal what is central to the success of the
software, what the business goal is and where the value is.
Amazons Approach To Product Development

Amazon have a unique approach when it comes to forming a domain vision statement called
working backwards . For new enhancements a product manager produces an internal
press release announcing the finished product, listing the benefits the feature brings. If the
intended customer doesnt feel the benefits are exciting or worthwhile then the product
23
manager will refactor the press release until the feature offers real value for the customer.
At all times Amazon are focused on the customer and ensure that they are clear about the
advantage a new feature can bring before they set out with development.
http://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management
Generic Domains
A Generic Domain is a subdomain that can be found in many large business systems. An example
of a generic domain is an email sending service, an accounts package, or report-suite. These
subdomains arent core to the business, but the business cant operate without them. As these
subdomains arent core and wont give you a competitive edge it doesnt make sense to spend a
lot of effort or investment in building them. Instead look to buy in software for generic domain.
Alternatively use junior developers to build these systems, freeing up more experienced resource to
work on whats core to your business.
Note, however, that a business defined by communication and targeted emails on limited time offers,
like a Groupon or Wowcher, could have its core domain as a sophisticated email/CRM system. What
is core to one business may well be generic to another.
Supporting Domains
The remaining subdomains in the system are defined as the supporting domains. These are
subdomains that, while not defining what your system does, help to support your core
domains. For example, Amazons supporting domains would be the functionality that enables a
customer to browse a catalogue for products. Amazons product browsing functionality doesnt
define it as a company and neither is it that different from any other e-commerce site, but it does
support the tracking of user journeys in order to feed a recommendations engine.
As with the generic domains, if possible, you should look to buy off-the-shelf solutions. Failing
that, do not invest heavily in these systems; they need to work but do not require your prolonged
attention. Its important to note that you may not always need to implement a techniqual solution
to a supporting domain. Perhaps a manual process could meet the needs of the business while
developers focus on the core domain.
The Core Domain Doesnt Always Have To Be Perfect First Time

In an ideal world quality software would always be top of your agenda, however its important to be
pragmatic. Sometimes a new systems core domain could be being first to market, or sometimes a
business may not be able to tell if a particular idea will be successful and become core to its success.
24
In this instance the business want to learn quick and fail fast without putting in a lot of upfront
effort.
The first version of a product that is not well understood by the business may not be well crafted.
This is fine as the business is unsure if it will be invested in over time, and the development team
should understand why the business want speed of delivery over supple design. However, if the
product is a success and there is value in a prolonged investment in the software, you will need
to refactor in order to support the evolution, otherwise the technical debt racked up in the rush to
deliver will start to become an issue.
Subdomains Exist In The Problem Space

Understanding the subdomains of your system enables you to break down the problem space.
Subdomains are abstract concepts; dont get subdomains confused with the organisational structure
of a company. Subdomains represent areas of capability, define business processes and represent
the functionality of the business.
Try not to bring technical concerns into conversation when you are analysing the problem space.
Security is a technical concern unless your problem space is security. Audit trails and logging are
also infrastructural concerns. Instead keep focused on the domain first and foremost. Understand
your problem space fully before rushing to implement your solution space.
2.4 Model In Context

So now you understand what parts of your system are core to the success of it. You are inline with
the vision of your business and you know where the value lies. Armed with this information you
can focus on models in context. Within each subdomain could live a specific model or two. You
must apply your knowledge crunching techniques to theses subdomains to reveal a more concise
and focused model of the domain.
Context is a very important term in Domain-Driven Design. Each model has a context implicitly
defined with a subdomain. When we talk about a product in the context of the fulfilment subdomain
we dont need to call it a fulfil-able product, likewise when talking in the context of shopping its not
a saleable product. Its simply a product in a defined context.
When we communicate with domain experts or other members of the development team we ensure
that everyone is aware of the context that we are talking in. The context defines the scope of
the model, limiting the boundaries of the problem space, enabling the team to focus without
distractions.
25
Multiple Models.
Without Context We Are Nothing

In many of the the larger enterprise applications you will work on there could be several of the
identified generic, core and supporting domains coexisting. In each of these subdomains you may
well discover the same terms and concepts being used but different contexts of the business will view
the same concepts and interpret terminology in very different ways. For example the concept of a
product in a sales context will be vastly different than a product in a pricing context in the domain
of an e-commerce organisation. The sale context is interested in the description of a product along
with its colour, weight and reviews. In comparison the pricing context needs to understand if the
product is in a current offer or if it is applicable to discounts that are dependant on the type of
customer purchasing the product.
In the figure below we see the concept of a product existing without an explicitly defined context.
It has been distorted in order to satify the needs of many different models.
26
Overlapping terms in subdomains.
Context Game
In order to demonstrate the importance of modelling in context and to reveal multiple models within
the domain you can employe another facilitating game. The Context Game, a game that I learnt from
a Greg Young , helps to make it clear where an additional model is require to map the problem space
effectively.
You can introduce the game into knowledge crunching sessions when you think you have an
overloaded or ambiguous term. Split the group into smaller groups of developers and business
experts. You should split the business experts by department or business responsibility. Give them
20 mins to come up with a definition on what the term or concept means to them in their part of
the business, using the developers to capture the knowledge. Then bring the whole team together
to present their views on the concept.
You will find that different parts of the business have different views on the shared terminology.
http://codebetter.com/gregyoung/2012/02/29/the-context-game-2/
27
Where the business functions have a difference of opinion this is where you need to draw your
context lines and create a new model. This is shown in the following figure with the product concept
exisitng in many different contexts.
Putting terms into context and identifying multiple models.
Multiple Models In A Subdomain

Within a single subdomain you may find more then one context and therefore more than one
model. Notice in the diagram below that the fulfilment subdomain has a replenishment model, pick
algorithm model and separate allocation model. The reason for this is that even in the boundaries
of the fulfilment subdomain the concept of a product will mean different things to different areas
of fulfilment. The replenishment model will only be concerned with the identity of a product and
how often it is purchased rather than a full description of it. The pick algorithm model will treat a
product as an item that is stored in pickable and bulk storage locations. The allocation model will
only know about the availablity of a product for ordering. Therefore we will create a model in each
of the different contexts each containing its own version of a product concept.
28
Subdomains can contain more than one bounded context
2.5 Shifting Focus From The Project To The Product

One of the fundamental shifts in mentality required for writing software for complex core domains,
from both the development team and the business, is to focus on the product rather than view it
as a standalone project. Often the development of software for a business product may never be
finished; instead the product under development will live through periods of feature enhancements.
The software is invested in until it is no longer providing value for the business or it cant be enriched
with further modifications.
Your product is an evolving succession of feature enhancements and tweaks. Just as developers
iterate so to do the business. A good idea becomes better after it is improved upon and fleshed out
over time. Understand the value of the product you are working on, what return on investment
will it bring to the company? Talk to your business sponsors about the future of the product to help
focus your coding efforts; know what is important to them.
Less Hast More Speed

All too often software for the core domain of a business isnt viewed as a product that requires care
and attention. Instead business software sacrifices quality and long-term investment for speed to
market. Too much emphasis is placed on thinking about the project and looming deadlines rather
than investing in the product for the future. This results in a code base that is hard to maintain and
enhance, and falls into the architectural pattern of the Big Ball of Mud, as discussed earlier in this
chapter.
The flip side however, is a prolonged release date which is often non-negotiable if other business
interests are dependent on the launch date of the software. The solution to this quandary is to look
to de-scope features in order to keep quality high and the deadline on track. To be in a position to
29
do this you must understand and share the vision and ultimate goal that the software is expected
to meet. This Understanding will enable you to include only the most important features of the
product and ensure it delivers the value expected by the business.
2.6 The Salient Points

Knowledge crunching is the art of processing domain information in order to identify the
relevant pieces that can be used to build a useful model.
Knowledge is obtained by developers collaborating with domain experts.
Only capture relevant domain knowledge that will help you solve your problem or build
your product.
Value domain knowledge as much as technical knowledge.
An analysis model is useful if it stays in synergy with the code model.
If you are shaping the analysis or code models you have to be hands on and contribute
to code. There is a place for architects but they must be coders as well.
Domain experts are anyone in the organisation that can offer insight into the domain
i.e. users, product owners, business analysts, other technical teams.
Knowledge is gained around whiteboards, brainstorming and prototyping, in a collaborative manner with all members of the team.
A model of the domain is created to represent the policies, rules and workflows of the
business in software.
Distillation is used to break down a large model in order to discover the the core, supporting
and generic domains from within the mass of domain knowledge.
Focus and effort should be invested on the core domain.

The core domain is the reason you are writing the software.
Outsource, buy in or put juniors on the supporting and generic domains.
A domain vision statement will reveal what is core to the success of a product,
understand this.
3 Speaking The Language Of Your

Domain
Its amazing how easily people with no technical skills can diagnose complex
software problems. @jacksonh
Understanding what your business considers core to the success of the product is one thing, but you
need to be able to talk about it with domain experts in a language you all understand. The benefit
of this is that both developers and domain experts can collaborate to solve problems in the domain
space without having to translate technical concepts. This language should be used throughout the
product, from class and method names to test scenarios.
3.1 The Language Of Domain Experts

I recently went curtain shopping with my wife and I must admit that while at the curtain shop I
had no idea what the shop assistant was talking about. Pleated, hang length, interlining, these were
all terms that mean something specific in the domain of curtain makers. Employees in the shop
could spend an age describing to each other what they wanted but this could lead to ambiguity in
meaning. Instead using terms in the domain of a curtain shop keep conversations short and concise
and everybody who understands the domain understands their meanings.
Its the same with carpenters, financial traders, the military and a nearly every domain you can
imagine. Each has terms and concepts that mean something very particular to them. A
secret language that enables complex topics to be covered in concise and meaningful dialogue
without the need for confusing waffle. It is vital for a development team to understand and
collaborate on this language, known as the ubiquitous language (UL). Its terms and concepts need to
be used when communicating with team members including domain experts, as well as being used
to name classes, methods and namespaces in the code base itself.
When collaborating with domain experts create a glossary of domain terms to
avoid confusion and to help make concepts explicit.
3.2 Collaborating On An Enhanced Language

It is not only the explicit terms and concepts that the development team must learn from the business,
they must also collaborate with the domain experts to define the assumed or implicit concepts that
may not have terminology. These concepts must be named by the entire team and included in the
shared ubiquitous language. The team may also need to create additional terms for concepts that
30
31
dont exist in the problem domain but have been discovered and labelled during modelling in the
software.
The team must communicate with each other using the ubiquitous language. The development
team must use it in code, and the domain experts must use it when talking to the team. The
benefit of a shared language removes the need to translate from business speak into tech and
vice versa. It also removes the possibility of ambiguity and misinterpretation as everyone
understands the meaning behind the concepts.
The ubiquitous language should be clean and concise. Technical terms should be removed in order
not to distract from business concepts. Likewise domain terms not relevant for the software under
creation must also not be allowed to cloud the shared language.
Validating The Model Out Loud
Linguistic consistency can be used to validate the usefulness of a model. For example listen
to conversations about the model and focus on concepts in the design that dont fit or when
the model cant easily satisfy business scenarios.
.
Enhancing The Language With Discovered Terms

As you gain a deeper understanding of the domain you are working in your ubiquitous language
will evolve. Refactor your code to embrace the evolution by using more intention revealing method
names. If you find a grouping of complex logic starting to form talk through what the code is doing
with your domain expert and see if you can define a domain concept for it. If one is found separate
the logical grouping of code into a specification or policy class.
What Is A Specification?
A specifictation represents a business rule that needs to be satisfied by the domain model or
part of it. Specifications can also be utilised for query criteria. For example you can query
for all objects that satisfy a given specification.
.
The ubiquitous language should be visible everywhere, from namespaces to

classes, and from properties to method names, use the language to drive the design
of your code.
32
3.3 Working With Concrete Examples

In order to better understand the domain you are in its a good idea to take specific examples of
domain behaviour. Concrete examples of real scenarios help to cement process and concepts within
the domain. However its important to reveal the intention of the business process and not the
implementation. Talk only in business terms, dont get technical.
In the following dialog a business user is describing the process of customers at an e-commerce site
requesting a replacement for an order that wasnt delivered.
When a customer doesnt receive their goods, they can request a new order for free. They
will log into their account and click on the I have not received my items button. If they
have already been flagged as having received a free order then they cant get another
one without having spoken to customer services. Otherwise we will send them out a free
order and update the database to show that this customer has already claimed for a lost
item. We will then contact the courier to see if we can claim back the cost of the lost
order.
You will notice that in the description above the business user is not focusing on the business process
but rather the implementation concerns. The following sentence is not giving any value or insight
into the domain or business process.
They will log into their account and click on the I have not received my items button.
In the next sentence the business user is already second-guessing how you will implement the
business policy. Some experts may have some experience with databases and may go as far as
suggesting data schemas. Again, this gives the team no deep understanding of the domain.
If they have already been flagged as having received a free order then they cant get
another one without having spoken to customer services.
From this set of requirements a team not interested in the domain may simply implement what
they are told and will end up with a poor model that doesnt reflect the concepts and policies of the
domain. The impact of which could be a misunderstanding of what flagging the customer means,
it may mean more than simply a tick in a database column and perhaps the catalyst for a the start
of a seperate business workflow. Without understanding the domain and the intent of a feature the
developers wont appreciate the repercussions of just implementing what they are told.
33
Teach Your Domain Experts To Focus On The Problem And Not

Jump To A Solution
Training and collaboration will help business people focus on the process rather than the implementation; the problem space rather than the solution space. Below the previous requirements statement
has been rewritten using the language of the domain. It focuses on the business and its processes:
If an order is not received an undelivered order notification can be submitted. If
this is the first claim then a replacement order is created. If a claim has been made
before a claim case is opened and assigned to a customer service representative who
will investigate the claim. In all cases a lost mail compensation case is opened and
sent to the courier with details of the consignment that was undelivered.
In this description we have discovered many important domain concepts that were missing before. In
the rewritten prose we have introduced some terms into the ubiquitous language and the terminoloy
of the domain has been made crystal clear. In fact the second description doesnt even contain the
customer concept; Instead it focuses only on terms that are directly related to the process.
Remember domain experts have no, or limited, understanding of technical terminology. Keep examples focused on the business and if they are trying to help you out by jumping to implementation
details just gently remind them to focus on the what and why of a system and ask them to leave the
how up to you.
Using Features And Scenarios To Demonstrate Domain Scenarios

Even though the second description of the process of a customer requesting a replacement order is
far better than the first it is still a bit wordy. More complex examples could be open to interpretation.
To combat this you can utilise features and scenarios to capture requirements and business process
in a clean and concise manner.
A feature describes a behaviour that the gives value to the business. In a feature story a role and
benefit is also included. The clarity of role that relates to the feature enables the development team,
along with domain experts to understand who to talk to or who to proxy. The benefit justifies the
existence of the feature, helping to clarify why the business user wants the feature.
The feature below describes the benefit given to customers at an e-commerce site requesting who
have not received their orders.
Feature: Enable customers to request replacement orders
In order to receive goods that have not been delivered
As a Customer
I would like to be able to notify customer services
34
In order to better understand a feature and its behaviour, scenarios are written to describe the feature
under different use cases. Scenarios start with an initial condition, the Givens. It then contains one
or more events, the Whens, and finally the scenario describes the expected outcomes, the Thens.
The scenario below shows the behaviour of the feature for a customer who has never claimed for
an undelivered order.
Scenario: Customer making his first claim
Given I have not received my items
And I am a customer that has never notified customer services of an undelivered order
When I notify customer services
Then I should receive a replacement order
In addition to being a light way of capturing requirements the scenarios provide acceptance criteria,
which can be used by developers and testers to determine when a feature is complete and by business
users to confirm to them that the team understand the feature.
The next scenario describes the behaviour for a customer that has already made a claim.
Scenario: Customer making his second claim
Given I have not received my items
And I am a customer that has made a successful claim for a replacement order
When I notify customer services
Then I should be contacted by customer services
Using this method of capturing requirements removes the ambiguity that traditional requirements
documentation can result in whilst also heavily emphasising a focus on the domain language. The
features and scenarios themselves are a product of a collaboration between the development team
and business experts and can help to shape the ubiquitous language.
3.4 A Language Tied To A Context

In the same way that we defined the boundary of responsiblity for a subdomain we must also ensure
the ubiquitous language is bound and specific to context within a subdomain. For example terms
like customer, order and product will be found in many of the contexts of an e-commerce domain.
So its important to be specific in code (using namespaces) and communication about what context
you are talking about.
It is also important to be explicit about what context you are using when talking with domain
experts, as terminology can have different meanings in different contexts. As mentioned in the
previous section multiple models will be at play in you domain. It is essential to enforce linguistic
boundaries to protect the validity of a domain term.
35

Learn domain terms and concepts, incorporate them into a shared language
Domains are full of specialist terms and language that describe complex concepts in a
clean concise manner
Implicit ideas in the domain that need to be understood by the team are made explicit
and given names that form the shared ubiquitous language
Care about the conversation
Make the implicit explicit
Developers should think in domain terns and concepts and not technical terms
Avoid the need to translate from business jargon into technical jargon
The ubiquitous language should be used in namespaces, class names and methods
Validate the language
Domain experts should object to inadequate terms or structure in the language or model
Developers should watch for ambiguity or inconsistency
Validate assumptions about the ubiquitous language by talking to domain experts
Validate out loud and confirm you ubiquitous language with linguistic consistency
If a domain expert doesnt say it it shouldnt be in the language
Capture requirements and language with feature stories and scenarios

Use domain scenarios to valid the teams understanding of the domain and the shared
language
If a term in the model no longer makes sense or is not useful then remove it, keep your
language small and focused
Use the ubiquitous language in specifications, tests and stories
4 Shaping Your Solution Space

You have now learnt how to define the subdomains of the problem space. And that many models
exist in large and complex problem domains. It is vital to protect the integrity of these models and
clearly define the boundaries of their responsibility in code. This section of the book introduces
the strategic patterns of Domain-Driven Design that show you how you can protect and integrate
the multiple models of an application. Enabling you to take the abstract problem domain and turn
it into a concrete technical implementation.
The diagram below shows the strategic patterns of Domain-Driven Design that will be covered in
this chapter.
A blueprint of the solution space of Domain-Driven Design.
4.1 Retaining The Integrity Of Models In Subdomains

As introduced in the previous sections a model is defined in a context. This should be followed
through to the implementation in the code otherwise we will find ourselves in a Big Ball of Mud.
Take the example of a code model that contains the concept of a product. As discussed this means
many things to many models in many contexts. If we dont enforce a boundary around the model
and make it specific to a given context we will end up with a mass of sprawling code.
36
37
It is important when developing the application that you isolate models within subdomains to
avoid the blurring of responsibilities which can lead to code that resembles a Big Ball of Mud.
The Challenges Of Maintaining A Single Model: Blurred

Responsibility
In the following diagram we see the concept of a product implemented within the e-commerce
application. You can see that there are no explicit boundaries protecting the integrity of the
product concept within each subdomain. Instead the product concept is being shared between
all the subdomains and has to contain both the data and behaviour to handle the needs for each
different context. The lack of any defined boundaries will lead the code, and the language, to
become a mess. The product entity will have many reasons to change as the subdomains evolve,
thus breaking the Single Responsibility Principle. In this example the persistence schema will also
become unmanageable due to the mess of overlapping concerns.
A single view of an entity in the domain for all subdomains can quickly become a problem.
38
You can see from the diagram above that the product class looks like it should belong to an enterprise
model. An enterprise model is typically used to a create a model of the entire problem domain.
Enterprise models can quickly become large and unwieldy due to all of the contexts they need to
serve, as is shown in the following diagram.
The product god object.
This is the manifestation of the Big Ball of Mud pattern as discussed earlier. A change to logic in
one of the subdomains will have an undesired knock-on effect to unrelated subdomains due
to the interwoven code and the lack of clearly defined boundaries of responsibility.
Bounded Contexts: Define A Boundary Of Responsibility Around

A Model
In order to remove ambiguity we must create explicit boundaries around each of the models
that define the applicability of the model within the context of the domain. Going further we
can even include the thin vertical stack of responsibilities within the boundaries of context,
including the presentation and persistence layers.
However no model is an island so once we have isolated each domain model we must define a
39
communication boundary so that all models can collaborate to produce the functionality of the
application.
Domain-Driven Design introduces the concept of a bounded context. A bounded context wraps
each model and ensures that the code it contains is solely focused on that specific context.
Any issues that are outside of the bounded contexts boundaries should not distract from its
responsibilities.
Bounded contexts protect the integrity of a model.
The Difference Between A Subdomain And A Bounded Context

The subdomains previously introduced are abstract and exist to help us understand the
problem space of a large and complex domain. A subdomain can contain many models all
which need to be protected to stay pure and focused to a given context. A bounded context,
unlike a subdomain, however, is concrete technical implementation that enforce boundaries
between models within an application.
.
40
Implementing A Bounded Context

Lets take another look at the e-commerce application now with the models of the subdomains
isolated from each other. In the diagram we can see that each bounded context looks after its own
presentation, domain logic and persistence responsibilities. In this improved architecture the concept
of a product can exist in each bounded context and only contain attributes and logic prevalent to
that context alone. Changes in any bounded context no longer have undesired effects on others as
the subdomains are now isolated.
The figure below shows a layered architecture pattern applied within bounded contexts as opposed
to across the entire application.
A layered architecture pattern per bounded context and not per application.
The following figure shows the that the Product class exists in two different contexts defined using
namespaces.
41
The Product class in different contexts.
4.2 The Importance Of Bounded Contexts

Domain experts maybe confused with you introducing more concepts such as a bounded context.
However its important that they understand the purpose of protecting the different model contexts
of the domain. Play the context game (introduced in Understanding Your Problem Space) in order
to help their understanding.
When we were defining smaller focused models in the problem space we talked about a model in
context. The context referred to the specific responsibility of the model. This helped us organise
the problem space. A bounded context takes the idea of a model in context further by encapsulating
it within a boundary of responsibility. This boundary is a concrete technical implementation, as
oppose to the context which is more abstract. The bounded context enforces communication in
such a manner as to not lessen the purity of the model.
In the figure below you can see that a bounded context exposes an endpoint for clients and other
models to communicate through. This end point can take the input of a different model and
transform it into a language that the model inside understands. This protects the integrity of the
model and helps to prevent blurred lines of responsibility.
42
The anatomy of a bounded context.
A Bounded Context Can Cover More Than One Subdomain

Some bounded contexts can cross many subdomains. For example take the communication
subdomain that deals with email. In the figure below we can see that the shipping, promotion
and loyalty subdomains all have needs to notify customers and so this responsibility makes up part
of that subdomain.
43
A bounded context can cross multiple subdomains.
More Than A Single Bounded Context Per Physical Deployment

Physical deploys such as applications or services may have one or many bounded contexts within
them. The number of bounded contexts will be decided based on the number of models for a given
subdomain. However more than one subdomain can exist in a single application, as is shown in the
following diagram.
44
Applications and services can contain any number of bounded contexts.
Sizing Your Models And Bounded Contexts

The size of your bounded contexts will be in direct relation to the responsibilities and size of your
models. Smaller models will require more communication and transformation between bounded
contexts. It may also be harder to see the bigger picture with smaller focused models. On the
other hand smaller models and thus smaller bounded contexts will make it easier for teams to own
and comprehend the responsibilities and capabilities of the model. Larger models and bounded
contexts will make communication easier but may dumb down the purity of the model. Teams
may no longer be able to own a model in its entirety and the coordination of changes may become
problematic. There is no secret recipe on how to determine the sizing of models, the more you
understand the domain and communication within and across subdomains, the better placed you
will be to determine how you model it.
The Language Of The Domain Shapes The Bounded Contexts

An effective way to identify bounded contexts is to look at the natural boundaries of
language within the problem space. Domain experts terminology and implicit word
45
boundaries can reveal how to carve up your solution space.

.
4.3 Architectural Patterns Apply To Bounded Contexts

Not Systems
A bounded context owns the slice of functionality directly related to the subdomain, this is from the
presentation layer, through the domain logic layer, then onto the persistence and even to the data
storage. Not all bounded contexts need to share the same architectural pattern. If a bounded
context contains a supporting or generic domain with a low logic complexity then I would
favour a more CRUD style of development. If however the domain logic is sufficiently complex
I would advise on creating a model of the domain. I will cover Domain Models in the next section.
What Is CRUD?
CRUD is an acronym for create, read, update and delete. It is often used to describe systems
with little logic that a merely forms over a data model. To many developers CRUD is a
four letter word (ok it is), but they think a simple solution may be beneath them. Dont
be frightened of applying a CRUD style architecture to an application. If you are dealing
with a bounded context that contains no logic then dont add lots of layers of abstraction.
Remember to KISS (Keep it simple stupid).
.
The figure below shows how different architectural patterns can be used within each bounded
context of an application. The various bounded contexts are pulled together using a composite
UI to display to the user.
46
Different architectural patterns can be applied to the different bounded contexts.
Note however that bounded contexts dont always have to have separate data storage and can exist
in the same solution and class library project separated only by namespaces and different database
table names.
What Is A Composite UI?
A composite UI is a user interface made up of loosely coupled components; bounded
contexts.
.
4.4 Understanding The Relationships Between

Bounded Contexts
With a clear boundary of responsibility models can evolve cleanly. However on all but the most
trivial of applications models withn bounded contexts will need to collaborate in order to fulfil a
47
business request. It is fundamental to understand how the bounded contexts in your domain interact
and collaborate to solve business problems. This collaboration map, know as a context map can help
to validate your bounded contexts and your understanding of the problem domain.
In many ways the communication between bounded contexts is often more important in terms of
domain knowledge validation than the bounded contexts themselves. A context map exposes the
systemwide relationships between bounded contexts and shows how subdomains interact. It
can also help to reveal issues with communication and workflows within the business.
Context Maps Clearly Show Business Process

My Theory #231: If you cant draw a decent diagram of it, dont even try and build
it. #software Dr Bunsen Honeydew (@bunsenhoneydew)
The context map needs to be understood by all development teams in the organisation. Teams dont
need to understand the inner workings of each bounded context, instead they need to be aware of
those other contexts, the API they expose, the relationships they have and most importantly what
bounded contexts they are responsible for. With this information teams can prevent blurring the
lines of responsibility and ensure all contexts retain their integrity.
Context maps that show bounded contexts are vital to keeping a system well-designed. Its also
important to realise that context maps must reflect reality and show the code in the present and not
what you want it to look like in the future. Context maps need not show the detail of a model but,
must instead, demonstrate the integration points and methods of model relationships.
Retaining integrity is important to keep your code base focused on a single bounded context. This
will enable the code to become supple as any change will only impact a single bounded context
and wont have a rippling effect across multiple areas of your domain. Its this suppleness that will
enable you to alter code and to adapt quickly and confidently when the business needs a change to
process or logic.
Bounded Contexts Work Together To Solve Business Problems

In the diagram below we can now see the interactions between the various bounded contexts. In this
example the shopping bounded context is responsible for calculating the total cost of a customers
basket. In order for a basket total to be calculated the shopping context needs to collaborate with
other contexts.
48
Bounded contexts interacting to fulfil a business request.
Firstly the shopping context uses the allocation context to determine if all of the items in the
customers basket are available to purchase. Once this is determined it passes the list of products
to the shipping context which calculates the shipping costs for the available products. Finally the
shopping context passes the list of products and a customer id to the pricing context. The pricing
context then calculates the prices of the products as well as determining if there is any discount for
the customer from the loyalty context.
A simplified view of the context map, as shown in the figure below, can be easily drawn by any
member of the team to aid discussion of business processes and workflows.
49
A context map showing the relationships between bounded contexts.
You can see that each of the Bounded Contexts are responsible for a specific subdomain within
the e-commerce application. The Context Map gives a high level view on how each of the contexts
interact. The Context Map is not only useful to the development teams, it can also demonstrate
issues with process and workflow across the business that they may not have been aware of.
4.5 Integration Between Bounded Contexts

As discussed in the previous section clear relationships between bounded contexts are vital in order
to understand business process. Important still is the manner in which these bounded contexts
communicate. DDD presents a number of patterns to standardise these communication methods.
Modules (aka .Net Namespaces)

Bounded contexts can exist in the same process so we can employee simple namespaces to define
the boundaries and keep models separate.
50
Anti Corruption Layer

You wont always be working on greenfield developments, and you may very well need to integrate
with a third-party set of libraries. Because you cant change the API of the contexts you dont own or
that cant be changed easily its important that you dont compromise the integrity of your bounded
context to match the API of another.
As shown in the figure below an Anti Corruption layer can be used to wrap communication with
legacy or third-party code in order to protect the integrity of a new bounded context.
Use an Anti Corruption Layer to integrate with code you dont own or cant change.
The translation map, shown in the following figure, works in a similar manner to the adapter pattern
in that it transforms the API of another context into an API that you can work against. The diagram
below shows how the transformation occurs between the bounded contexts.
51
Translations occurring within an Anti Corruption Layer.
Introducing Bounded Contexts Into Legacy Code

Not all of a large system will be well designed. Eric Evans
If you have a system that resembles a Big Ball of Mud it is sometimes not cost effective to simply
rewrite. This is mainly due to the fact that even though messy, that legacy mess is an asset to the
business and they will be reluctance to throw away something they have invested a lot of money
and time in. Instead lean on the Anti Corruption layer in order to isolate the new context from the
existing code mess. Using an Anti Corruption layer in this context is a great refactoring practice as
you are able to create clear boundaries without the need to update the mess of code that lives within
a context. The diagram below shows how legacy code can be carved up without having to resort to
a large rewrite.
52
Refactoring legacy code with an Anti Corruption Layer.
Shared Kernel
If two teams are working closely in the same application, on two separate bounded contexts that
have a lot of crossover in terms of domain logic, the overhead of keeping the teams isolated and
using translation maps to translation from one context to another can be too much. In this instance
it may be better to collaborate and to share a part of the model to ease integration. This pattern is
of particular use if you have two bounded contexts in the same subdomain that share a subset of
domain logic. The diagram below shows two bounded contexts sharing a sub model.
53
Integration with a Shared Kernel.
It is important to ensure both teams share the code and dont implement updates without first
agreeing the changes and the impact of those changes. I also find that a shared kernel is often
best used in the same subdomain as shown in the diagram above.
Open Host Service

If a bounded context has many relationships, and each relationship requires a translation map, it can
be more productive to publish a set of services typically via a SOAP or as a RESTful service instead
of integrating manually. The diagram below shows a recommendation engine exposing an API to
other subdomains that can utlise its information.
54
Integration with a Open Host Service.
Publish-Subscribe
The publishsubscribe messaging pattern which follows an event-driven method of programming,
where publishers send events (as messages), of something that has occurred, to subscribers that are
unknown to them. It is then up to the subscriber to register interest in the message being sent.
In the diagram below we can see how the sales bounded context communicates with other bounded
contexts by publishing events. Many different integration methods can be used to transport the
messages such as message queues and web services.
55
Integration with Publish-Subscribe.
4.6 Patterns For Team Work

A single team should be responsible for a bounded context whether that crosses
many applications or departments.
Amazon has a policy of ensuring no development team is so big that it cannot be fed by two pizzas .
It is important to keep teams small and focused, and make them responsible for a bounded context
or set of bounded contexts. As highlighted by the context map, not all bounded contexts work
in isolation, and just as there are patterns to communicate in code between bounded contexts
so too are there patterns for team collaboration.
Structure teams around bounded contexts; form product and services groups rather than
trying to mirror the departmental structure of the business. Ensure teams are responsible
for a bounded context from presentation, through domain logic and to persistence.
http://highscalability.com/amazon-architecture.
56
Customer-Supplier (Upstream/Downstream)
The following example, shown in the figure below, shows the relationship between a pricing context
and an allocation context. The pricing context is reliant on the allocation context to tell it the
availablity of items, in order for the pricing context to total the sale. If the business wanted to
enhance this feature and give lead times to the out of stock items, the team responsible for pricing
would need to ask the allocation team to update their solution to not only return if the item was in
stock but also include a lead time for when stock would arrive.
The Customer-Supplier relationship.
The two teams would be in a Customer-Supplier relationship, with the team responsible for the
sales context taking the role of customer and the team responsible for the availability context taking
the role of supplier. It is important that both teams understand the business intent and purpose of
a change to ensure that they are working towards the common goal. It is also important that the
teams collaborate on the changes to the boundary and the API of the availability context.
Conformist
In the example I gave for the Customer-Supplier team pattern it was assumed that both teams were
working in the same organisation and so were part of a larger team that would naturally help each
other out. However if you find that you are downstream of a team outside of your organisation, or
working with a team that is not as flexible when asked to alter boundaries then you will fall into the
Conformist team pattern. Under this relationship you have to live with the boundary defined by the
upstream team. In order to work effectively with the other team it is sometimes better to confirm
to their published language and model rather than spend lots of effort on translations through the
use of an Anti Corruption layer.
57
Partnership
If a business wish requires changes to multiple bounded contexts in order to be delivered then
teams must work in a partnership. The different teams responsible for the various bounded contexts
must work together on the common goal and have a shared understanding of the context map and
integration points around each of their bounded context.

Bounded Contexts
Protects the integrity of the domain model

Dont bend interfaces for the client instead expose capabilities
Needs vs Capabilities
You dont have a domain model in all of your bounded contexts. If no logic use CRUD.
Speak a ubiquitous language within an explicitly bounded context
Context Maps
A context map reflects the way things are right now. It shows the integration methods
and points between bounded contexts as well as the patterns of team work.
Context maps are a key concept, they define how bounded contexts interact and provide
the glue to integration across the domain.
Integrating Bounded Contexts
Anti Corruption Layer
* Use to isolate and integrate with legacy systems
Open Host Service
Publish-Subscribe
Shared Kernel
Patterns for team work
Customer-Supplier (Upstream/Downstream)
Conformist
Partnership
5 Complex Core Domains Should Be

Based On A Model
There are no right or wrong models, only what is useful.
If your core domain contains enough complexity it is important to base it upon a conceptual model of
the problem domain. The model describes the entities, processes, polices, concepts, relationships and
the constraints of the business domain. The model contains both explicit and implicit concepts,
and is written using the terminology of the ubiquitous language. It is not an exact replica of
the real problem space but more a representation tailored for the needs of an application.
The figure below highlights a bounded context that is core to the system that is complex and will
evolve. This is a great candidate for being based on a model of the problem subdomain.
Model-Driven Design and its place within the DDD blueprint.
5.1 The Domain Model: Expressing The Model In Code

Business people dont talk about buttons on web pages or about databases, they talk about business
processes and procedures. Take the process of a customer reporting that an item has not been
delivered to them. There are rules around what we might do; if this is the first time a customer
has complained of a missing item and its of a low cost we may send out a replacement for free.
If we sent out the original item via courier then we can check the status of the shipment with the
carrier. If the item was sent via standard mail and therefore cant be tracked, then we must ensure
a free replacement is shipped via traceable delivery method. These rules and logic are what the
business cares about and is what you should model.
58
59
Model Only What Is Relevant

The domain model exist for one reason - to serve the application under development. Dont try and
model real life, only model what is useful and what will help you solve the problems defined in your
domain that relate to the application being built. Constantly challenge the model you create against
new scenarios and validate your understanding with domain experts. Unlike other enterprise or
object models a domain model contains both behaviour and data. The behaviour represents
the policies and logic within the problem domain.
A Clean Model
The rules, polices, concepts and workflows of the domain should be represented in the domain
model, separate from the presentation and persistent concerns. The domain model is where you
will invest most of your time. You will work closely with domain experts to produce a useful model
to solve problems within the domain space. Even though it will only make up a small portion of the
code base it is the most important artefact. This is because the UI and persistent concerns will, to a
large degree, remain static, its the rules and policies of your business that will need to evolve over
time. The area of the code base that represents these rules and policies must be supple enough to
change with it.
In reality only a small part of your application will represent a model of the domain, the rest will be
taken up by infrastructural and presentational responsibilities as can be seen in the diagram below.
60
The code that represents the domain model only makes up a small portion of the overall code base.
Persistence Ignorance
The figure below shows a very simple domain model for financial loans. The objects in the
diagram represent concepts in the domain and are simple .net classes also know as POCO (Plain
Old C# Objects). These classes are free from infrastructure concerns and are completely persistence
ignorant.
61
A simplified Domain Model for financial loans.
The domain model is ignorant of any persistence concerns. When designing the model we dont
start first with a data model, instead we start with the code model. We strive to keep the model pure
and only compromise if our persistence mechanism deems that we must.
Dont Model Reality

Dont let the truth get in the way of a good model.
A common misunderstanding is that a Domain Model should match reality; in fact you should not
look to model real life at all but rather model useful abstractions within the problem domain. Look
for commonalities and variations within the problem domain. Understand which are likely to
change and that are considered complex. Use this information to build your model. It will be
far more useful than identifying nouns and verbs based on the world of the problem domain.
Remember to be selective when creating your domain models, you dont have to include everything.
Businesses are big and complex with a lot going on, to try and create that world within a single model
would be at best foolish and at worst extremely time consuming and well rather pointless. Needless
to say it would be a maintenance nightmare, if you are modelling a large system break it down to
more manageable chunks by clearly sectioning off parts of the model.
62
Try not to model real relationships instead define associations (meaningful connections) in terms of
invariants and rules in the system. In real life a customer has both a credit history and a contact email
address but how often would you come across a rule that in order to purchase an item a customers
credit history must be a good and they must have an email address starting with A. Instead group
behaviour and data together in order to satisfy the needs of the problem domain rather than
what you think might belong together.
A Useful Abstraction On Reality

The London Tube map was a designed to solve a problem, is doesnt reflect real life. It isnt
useful for calculating distances between landmarks in London, but it is useful for travelling on the
underground. Its simple and effective within the context that it was designed for.
London Tube Map barring no resemblance to the distance between stations
As we are not concerned with modelling real life the domain model cannot be deemed as being
wrong or right rather it should be viewed as useful or not for the given problem it is being used to
solve.
Reveal The Behaviour Of The Domain

An effective domain model should express the intent of the business use case by aiming code at the
right level of abstraction. Readers should be able to quickly grasp domain concepts without having
to drill down into the code to understand the implementation details.
63
The Code Model Is The Only Truth

Solve problems with business users then use the same language in code. Speak
to domain experts without the need to translate. No talk of infrastructure only
domain concerns.
The code model is the realisation of the business model; it validates the assumptions of the business
and quickly highlights any inconsistencies with the business model. If during the creation of the
code model issues are found and logic doesnt seem to fit then the development team should work
with the domain experts to resolve these problems. This update to the code model is reflected in the
business model by making changes to workflow and polices that may not have expose issues before.
Likewise any changes from a business perspective need to be reflected in the code model. The code
and business models are kept in synergy. The code is the model, the code is the truth.
Hands On Modellers
Any member of the technical team that has a say in how the model evolves must be hands on. They
must have face to face time with the domain experts and the ability to modify and create code.
There is no place for ivory tower architects that do not have an investment in the domain and the
code base. Its crucial to be able to represent a model in code that has synergy with the problem
domain. It is this hands on approach that will enable deeper insight and breakthroughs which lead
to greater understanding of the domain.
5.2 Tactical Patterns: The Building Blocks Of Model

Driven Design
There are a number of design pattens; shown in the following diagram, that can be used in the
creation of a Domain Model. The patterns fall into two main groups:
Patterns to model the structure of a domain
These patterns are used to represent the policies and logic within the problem domain. They
express relationships between objects and model rules.
Patterns to model the life cycle of the domain
These patterns deal with the creation and persistence of the patterns that represent the
structure of the domain.
I will also introduce another pattern that does not fit into either of the above groups. This is the
Application Service pattern, and acts as a gateway API for your client. The application service
pattern is used to implement the bounded context and keep the model clean and pure. The rest of
this section introduces the tactical patterns of model driven design in detail.
64
The Building Blocks of DDD.
Model Structure Patterns

Value Objects
A value object is defined by its attributes and has no explicit identity; instead its identity is
determined by its attributes. The comparison of value objects should be made by comparing their
attributes. Because they are defined by their attributes value objects are treated as immutable, i.e.
once constructed they can never alter their state. A good example of a value object is money, it
doesnt matter that you cant distinguish between the same five one pound coins or one dollar bills
in your pocket. You dont care about their identity, only about their value and what they represent.
A Value Object.
In the following code snippet we see money modelled as a value object.

Money modelled as a value object in C#.
1
2
3
4
public class Money

{
protected readonly decimal _value;
private readonly Currency _currency;
5
6
7
8
9
public Money()
: this(0m, new SterlingCurrency())
{
}
10
11
12
13
14
15
public Money(decimal value, Currency currency)

{
_value = value;
_currency = currency;
}
16
17
18
19
20
21
public Money add(Money to_add)

{
if (this._currency.Equals(to_add._currency))
return new Money(_value + to_add._value, _currency);
else
65
throw new NonMatchingCurrencyException(

"You cannot add money with different currencies.");
22
23
24
25
26
27
28
29
30
31
32
33
public Money minus(Money to_discount)

{
if (this._currency.Equals(to_discount._currency))
return new Money(_value - to_discount._value, _currency);
else
throw new NonMatchingCurrencyException(
"You cannot remove money with different currencies.");
}
34
35
36
37
38
39
public override string ToString()

{
return string.Format("{0}",
_currency.format_for_displaying(_value));
}
40
41
// Equallity overrides
42
43
44
45
46
47
48
public static bool operator ==(Money money, Money money_to_compare)

{
if ((object)money == null)
{
return (object)money_to_compare == null;
}
49
return money._value == money_to_compare._value &&

money._currency == money_to_compare._currency;
50
51
52
53
54
55
56
57
58
public static bool operator !=(Money money, Money money_to_compare)

{
return (money._value != money_to_compare._value ||
money._currency != money_to_compare._currency);
}
59
60
61
62
63
public bool Equals(Money obj)

{
if (obj == null) return false;
return obj._value == _value;
66
67
64
65
public override bool Equals(System.Object obj)

{
if (obj == null) return false;
if (obj.GetType() != this.GetType()) return false;
66
67
68
69
70
return ((Money)obj)._value == _value;
71
72
73
public override int GetHashCode()

{
return (_value.GetHashCode() + _currency.GetHashCode())
.GetHashCode();
}
74
75
76
77
78
79
Notes on the code:

The equality methods have been overriden meaning that the money object is only compared
by its value and currency.
The object is immutable. Once it has been created it cannot change state.
The add method returns a new instance of a Money object. This is known as closure of
operations as we are not altering the state of the original Money object.
Another value object is used to capture the concept of a currency. Notice how we delegate
to the currency object when comparing equality, again the equality methods have been
overridden.
Entities
An entity represents a concept in your system that is defined by its identify rather than is attributes.
An example of an entity is an order of an e-commerce site. When an order is created it is given an
identity which will never change. However the details of the order may change, for example the
customer may want to change the shipping address or add additional items to the order. Entities are
mutable, their attributes can be altered but its identify will remain consistent. Therefore to compare
two entities we would compare only on identity, regardless of any similarities with attributes. Entites
are dedicated to identity keep attributes within them to a minimum. Instead push logic out into small
and focused value objects.
An Entity.
In the following code snippet we see a product modelled as an entity.

A product modelled as an entity in C#.
1
2
3
4
5
public class Product : Entity<Guid>

{
private readonly IList<Option> _options;
private Price _selling_price;
private Price _retail_price;
6
7
8
9
10
11
12
13
public Product(Guid id, Price sellingPrice, Price retailPrice)

: base(id)
{
_selling_price = sellingPrice;
if (!selling_price_matches(retailPrice))
throw new PricesNotInTheSameCurrencyException(
"Selling and retail price must be in the same currency");
14
_retail_price = retailPrice;
_options = new List<Option>();
15
16
17
18
19
public void change_price_to(Price new_price)
68
20
if (!selling_price_matches(new_price))
throw new PricesNotInTheSameCurrencyException(
"You cannot change the price of this product to a different\
currency");
_selling_price = new_price;
}
21
22
23
24
25
26
27
public Price savings()

{
Price savings = _retail_price.minus(_selling_price);
28
29
30
31
if (savings.is_greater_than_zero())
return savings;
else
return new Price(0m, _selling_price.currency);
32
33
34
35
36
37
private bool selling_price_matches(Price retail_price)

{
return _selling_price.Equals(retail_price);
}
38
39
40
41
42
public void add(Option option)

{
if (!this.contains(option))
_options.Add(option);
else
throw new ProductOptionAddedNotUniqueException(
string.Format(
"This product already has the option {0}",
option.ToString()));
}
43
44
45
46
47
48
49
50
51
52
53
public bool contains(Option option)

{
return _options.Contains(option);
}
54
55
56
57
58
Notes on the code:

The Product entity delegates all work to the Money and option value objects.
69
70
The behaviour of the entity is exposed but the data is hidden.

The entity has a generic base class that takes the type used for identification. Within the base
class lies the overridden equality methods similar to what you saw in the Money value object.
However this time when comparing objects we compare on type and the ID.
For completeness here is the implementation of the entity base class.
The entity base class in C#.
1
2
3
public abstract class Entity<TId> : IEquatable<Entity<TId>>

{
private readonly TId id;
4
5
6
7
8
9
10
11
protected Entity(TId id)

{
if (object.Equals(id, default(TId)))
{
throw new ArgumentException(
"The ID cannot be the default value.", "id");
}
12
this.id = id;
13
14
15
16
17
18
19
public TId Id
{
get { return this.id; }
}
20
21
22
23
24
25
26
27
28
29
public override bool Equals(object obj)

{
var entity = obj as Entity<TId>;
if (entity != null)
{
return this.Equals(entity);
}
return base.Equals(obj);
}
30
31
32
33
public override int GetHashCode()

{
return this.Id.GetHashCode();
71
34
35
public bool Equals(Entity<TId> other)

{
if (other == null)
{
return false;
}
return this.Id.Equals(other.Id);
}
36
37
38
39
40
41
42
43
44
Value Object And Entity Associations

The greater the number of associations between entities and value objects, the more complex the
object graph will become. To reduce complexity create relationships in a single direction. To
decrease the number of relationships qualify associations. Finally if the relationship is not required,
i.e. does not work to fulfil an invarient then dont implement it. Remember dont model real life.
The relationship may exist in the real domain but it may not be required for the model.
Aggregates and Aggregate Roots

Entities and Value objects collaborate to represent concepts within the domain. These collaborations
are used to ensure invariants are met. The entities and value objects that work together must be
consistent. When dealing with large object graphs as shown in the figure below it becomes difficult
to ensure all invariants are fulfilled.
72
A large object graph.
However we can ensure consistency is ensured by splitting large object grpahs and treating the
sub groups of entities and value object as an aggregate - an atomic unit. The aggregate forms a
boundary around the objects and controls access, ensuring changes dont leave the collection in an
invalid state.
73
A large object graph split into aggregates.
An aggregate is a meaningful conceptual grouping. It is better to construct aggregates around

invariants. Remember dont try and model real life, model only what is useful to support the business
policies and workflows. Aggregates should always be consistent but there can be inconsistencies
between aggregates.
What Is An Invarient?
Invariants are rules that enforce consistency in the domain model. Whenever there is a
change to an entity or aggregate the business rules must be adhered too. An example of
an invarient could be a rule that states a customer must always have a complete address.
To ensure we adhere to this invarient we would not give the user the opportunity to
independently edit lines of the address enabling it to become invalid. Instead we would
treat the address perhaps as a value object to ensure a change results in the invarient remaing
valid.
.
Aggregate Roots
74
An aggregate root acts as the entry point to the aggregate.
An aggregate root acts as the entry point into the aggregate. No other entity or value object outside of
the aggregate can hold a reference to any object within the aggregate. Objects outside the aggregate
can only reference the aggregate root of another aggregate. Any changes to objects in the aggregate
need to come through the root, the root act encapsulate the data of the aggregate and only exposes
behaviours to change it.
75
Relationships between aggregates.
Domain Events
Domain events signify things that have changed within the model. Events can be used to record
changes to a model in an audit fashion or they can be used as a form of communication across
aggregates. A lot of the time an operation on a single aggregate root can result in side effects that
are outside the aggregate root boundary. Other aggregates within the model can listen for events
and act accordingly.
For example consider the basket within an e-commerce site, every time a customer places an an item
in his basket we want to update the recommended products that are displayed on the site. In this
scenario after a domain event is raised with details of the basket each time it is modified. The event is
subscribed by the recommendatios bounded context. Without using a domain event we would need
to explicitly couple the basket bounded context to the recommendation context. Domain events give
a more natural flow of communication and focus on the when i.e. When a customer orders they
will receive loyalty points.
Domain Events.
In the following code snippet we see a domain event being published from a basket.
A basket publishing the event of a product being added.
1
2
3
4
5
6
namespace Domain.Shopping
{
public class Basket
{
private BasketItems _items;
private Guid _id;
7
8
// ....
9
10
11
12
13
public void add(Product product)

{
_items.Add(BasketItemFactory.CreateItemFor(product, this));
76
77
DomainEvents.raise(new ProductAddedToBasket(this._id,
_items.ids_of_items_in_basket()));
14
15
16
17
18
public class ProductAddedToBasket

{
public Guid basket_id { get; private set; }
public IEnumerable<Guid> items_in_basket { get; private set; }
19
20
21
22
23
public ProductAddedToBasket(Guid basket_id,

IEnumerable<Guid> items_in_basket)
{
basket_id = basket_id;
items_in_basket = items_in_basket;
}
24
25
26
27
28
29
30
31
// .....
32
33
In the following code snippet we see a recommendation service handling the event raised by the
basket.
78
The recommendation service handling the event.

1
2
3
4
5
namespace Domain.Recommendations
{
public class RecommendationsEventHandlers
{
// ......
public void Handle(Shopping.ProductAddedToBasket product_added)

{
_recommendation_service.update_suggestions_for(
product_added.basket_id, product_added.items_in_basket);
}
7
8
9
10
11
12
13
Domain Services
Domain services encapsulate domain concepts that just are not naturally modelled as value objects
or entities. They can represent behaviours that have no identity or state. They can also orchestrate
workflow that uses entities of value objects. A good example of a domain service is a shipping
calculator. This service is a business function that, given a set of product IDs and a collection of
courier entities, can calculate the cheapest shipping cost.
Life Cycle Patterns

Factories
If the creation of an entity or a value object is sufficiently complex you should delegate the
construction to a factory. A factory ensures that all invarients are be met before the domain object
is created. If a domain object is simple and has no special rules for valid construction favour a
constructor method over a factory object. Factories can also be used when recreating domain objects
from persistent storage.
A Factory.
79
In the following code snippet we see that a customer entity has a factory method to enable an address
to be created with a valid customer id.
80
A customer entity with a factory method.

1
2
3
4
5
6
public class Customer : Entity<Guid>

{
public Customer(Guid id)
: base(id)
{
}
// ...
8
9
public Address create(Address delivery_address)

{
return new Address(Guid.NewGuid(), this.Id);
}
10
11
12
13
14
Repositories
A Domain Model needs a method for persisting and hydrating an Aggregate. As an Aggregate
is treated as an atomic unit, you should not be able to persist changes to an Aggregate without
persisting the entire Aggregate. A Repository is an infrastructure concern and so it is not always
necessary to abstract away the underlying framework doing all the hard work. It can be more worth
while to lean on ORM frameworks to act as a Repository; examples include Nhibernate, RavenDB
and Entity Framework. A lot of developers get hung up on this pattern. Think of it simply as
a method of persistence and rehydratation. Treat it like infrastructure and dont get hung up on
abstracting it away.
81
A Repository.
Application Services
An Application Service at first sight may be similar to a domain service in terms of responsibility,
however it focuses not on the domain concerns but rather on the concerns of the application. The
Application Service calls into the domain service and domain entities in order to orchestrate business
requests. It does not contain any business logic only orchestration, security, logging and other
infrastructure concerns.
An application service.
Application services can also act across multiple models
82
83
An application service spanning across many domain models.
Infrastructure Services
Infrastructure services are a third type of the overloaded term service. They are primamrly used
with the infrastructure layer to abstract purely technical concerns. For example an infrastructure
service can be used to simpliy they interface of sending an email or sending a message on a message
queue.
5.3 Presentation Concerns: The Command Vs Query

Paradox
A domain model is great for maintaining state and ensuring rules and policies are adhered to within
the problem domain. However when it comes to displaying on the state of the domain a domain
model is often not a good fit due to its many object graphs used to model domain concepts.
84
In the following diagram we can see that a view requires information from multiple aggregates.
Using the domain model in its present state would require a lot of unnecessary objects being pulled
from the database in order to provide a tiny subset of data for a screen view or report. This clearly is
not what the domain model was design to do and is outside the context of where the model should
be applicable - put another way the domain model isnt a great pattern for display purposes.
Issues with presenting a view of the domain.
A better way to serve the needs of displaying the state of the domain is to use separate domain view
objects that are tied to a screen or report view. The domain views can be generated direct from the
database as in the figure below.
85
Pull domain views straight from the database.
Domain views can also utilise events to create materialised views or a separate presentation model
based on views.
86
Pull domain views straight from the database.

Model-Driven Design
Focus on behaviour
Capture more information than just the classes. Capture behaviour, business workflows/
activities, and constraints, polices and rules.
Verbs over nouns and behaviour over data. Look for the hidden concepts, things that
arent explicitly talked about
Understand the Tell dont ask Principle, encapsulate data behind behaviour
Reveal concepts in the domain
Bake the ubiquitous language into the code
The model and the code implementation shape together. A change in one is reflected in
the other and vice versa.
Defining relationships and associations (meaningful connections) is important
* i.e. What goes together in order to satisfy the needs of the problem domain
87
Life without a domain model for complex products produces code that does something
useful but without explaining how
The only truth
The domain model represents the single model for analysis (to understand the domain)
and design (software implementation). Care for your domain model like you would a
small plant, make sure you keep it updated.
There is a synergy between the code and the model
Dont model real life
Dont blindly model reality e.g. customers > Orders
A model is an interpretation of reality that abstracts only what is relevant to solving the
problem
Dont let the truth get in the way of a good model
* There is no spoon, there is no customer
Model useful abstractions of reality, there is no real life in the world of code
Forget all your OO training about nouns and verbs
Exclude irrelevant features, model only what is useful
A model is only useful for a time
New problems may require update to model
Care for the code quality of your domain model. There are two reasons why you want
to make sure that the code quality of the domain model is top-notch:
* The domain model is the foundation of your application, if it is bad, the whole thing
can fall apart
* It changes a lot. There are very few areas in your code that are going to change so
many times as the domain model
POCO free of infrastructure concerns; keep simple, readability over smart code.
A Model is defined within a context
Putting effort into defining contexts and boundaries is essential to get to good models
A model is a method for handling complexity
6 Refactor for Deeper Design Insights

A domain model should adhere to these two principles:
1. Be relevant: able to answer questions in the problem domain and enforce rules and invarients.
2. Be expressive: able to communicate to developers exactly why its doing what its doing.
The creation of a useful model is never completed at the first attempt. In fact often the initial
incarnation of a domain model will be naive and will contain very little insight into the rich problem
domain. Instead constant refactoring is required to expose domain knowledge within the code base.
6.1 Non Technical Refactoring

Experienced developers are familiar with employing technical refactorings to increase the quality
of the software construction by migrating to well-known code organising patterns. However a
different type of refactoring is required in order to meet the needs of the second principle - that of
code communication. Its important to reflect in code any domain knowledge breakthroughs that
happen with domain experts or indeed any one working on the software product. Code within the
domain model should be clear and expressive.
A domain model will start out simple based on a shallow view of the domain, usually based on the
nouns and verbs of the requirement documentation or from initial discussions with domain experts.
However as the depth of knowledge within the team grows through iterations so should the richness
of the domain model. Even if the technical design of the code has been modified to increase clarity,
the names and methods of classes, along with the namespaces, should continued to be updated to
reflect the more insightful abstractions that are discovered through knowledge crunching sessions.
This continued investment in the model helps keep it relevant and match the vision and intent of
the domain experts.
6.2 Making The Implicit Explicit

Its often the things the domain experts dont say or barely hint at that can be the key to unlocking
the design of a model. These implicit concepts which may not appear important to domain experts
should be made explicit, named and fully understood by the development team. For example
consider an e-commerce site that prevents customers from overseas adding more than 50 of any
one item to their basket. Developers could easily implement this business rule as can be seen in the
code snippet below.
88
89
Code with an implicit rule.

1
2
3
public class basket

{
// ....
5
6

{
if (basket_contains_an_item_for(product))
{
var item_quantity = get_item_for(product).quantity()
.add(new Quantity(1));
7
8
9
10
11
12
13
if (item_quantity.contains_more_than(new Quantity(50)))
throw new ApplicationException(
"You can only purchase 50 of a single product.");
else
get_item_for(product).increase_item_quantity_by(
new Quantity(1));
14
15
16
17
18
19
}
else
_items.Add(BasketItemFactory.create_item_for(product, this));
20
21
22
23
24
However in future months other developers may not understand why such a rule exists. Instead we
should understand the intent and why the rule exists and name the portion of code accordingly. As
it transpires such a rule is enforced by suppliers in order to prevent sites acting as wholesellers. With
this knowlegde we can make the code explicitly reveal this rule by wrapping it in a class which will
reveal a deeper insight and understanding of the domain. This refactoring is seen in the following
code snippet.
Code with an explicit rule.

1
2
3
public class basket

{
// ....
5
6

{
if (basket_contains_an_item_for(product))
{
var item_quantity = get_item_for(product).quantity()
.add(new Quantity(1));
7
8
9
10
11
12
13
if (_over_seas_selling_policy.is_satisfied_by(item_quantity))
get_item_for(product).increase_item_quantity_by(
new Quantity(1));
else
throw new OverSeasSellingPolicyException(
string.format(
"You can only purchase {0} of a single product.",
OverSeasSellingPolicy.quantity_threshold));
14
15
16
17
18
19
20
21
}
else
_items.Add(BasketItemFactory.create_item_for(product, this));
22
23
24
25
26
27
28
29
30
public class OverSeasSellingPolicy

{
public static Quantity quantity_threshold = new Quantity(50);
31
public bool is_satisfied_by(Quantity item_quantity, Country country)

{
if (item_quantity.contains_more_than(quantity_threshold))
return false;
else
return true;
}
32
33
34
35
36
37
38
39
90
91
Give Things A Name

If domain experts talk about it then make it explicit. If domain experts hint at a concept make
it explicit. If you talk about something that puzzles domain experts then maybe you have
misunderstood something they have said and you need to work on your ubiquitous language.
6.3 Challenge Your Assumptions

During every iteration the development team must challenge their assumptions as additional
features may mean that a previously-useful model is no longer fit for purpose. It is this skill that
will enable your software to be flexible and evolve as the product evolves and thus preventing it
from turning into a big ball of mud.
A team should not become too attached to a model based on the requirements from a first iteration.
Subsequent iterations may see the model become inadequate for the new feature requests. Teams
who are inflexible about evolving will soon find the code works against them. When teams follow
a test driven development methodolgoy they do not stop when the system is working. Instead they
first make a test pass then they refactor their design to make it more expressive. This is by far the
most important aspect of test driven development and one that should be applied to Domain-Driven
Design. Refactoring when knowledge is gained helps to produce a model that is more expressive
and revealing.
6.4 Supple Code Aids Discovery

Dont get too precious about your software, be prepared to throw away your best
code when the business model changes.
Watch out for premature refactoring. Dont refactor until you know enough about the domain.
Dont leave design up to interpretation, write insightful code that exposes the why and how.
Create side-effect free methods. Make a method a command that changes state or a query
that reports on it or answers a question based on it. See command or query Pattern
Use value objects wherever you can. Push logic into value objects and make entities light.
Favour immutability.
Learn To Unlearn
Dont get attached to ideas, trial and error is required to reveal concepts in the domain that
will help you to solve business problems. Code within the testing namespace alongside the
92
tests until you are happy with the design, you will be a lot happier to spike solutions and
throw away a useless model that you havent committed to the application namespace.
.
Constant refactoring toward deeper insight will help to create flexibility and this produces
a supple design. Places where code changes a lot will become more flexible and will help
facilitate change.
Martin Fowler model principle Design a model so that the most frequent modification of the
model causes changes to the least number of types.

Refactor for deeper insight
A domain model should communicate the intent of the business
Keep looking at the code in a different way, if you find coding is hard then you are
probably doing something wrong, dont just stop at the first useful model
Develop a richer domain model through model exploration and creativity
Dont refactor until you know enough about the domain Dont worry you wont get
it right the first time Code and model tightly related, during coding if a new concept
is distilled then update model and vice versa, needs to be bi-directional
Make implicit concepts explicit
Make implicit concepts explicit, code explicitly the concepts that have been hinted at in
discussions then feedback into model
Constant refactoring toward deeper insight will help to create flexibility and this
produces a supple design.
Places where code changes a lot will become more flexible and will help facilitate change.
7 What DDD is not

DDD is a philosophy born out of a need to realign the focus of development teams. It is not
a framework or a set of predefined templates that you can apply to a project. Where there is
value in design patterns and frameworks DDD emphasises the value in collaboration between the
business and development team to produce useful and relevant software. Teams should embrace
the problem domain they are working within and look outside of their technical tunnel vision. The
most fundamental point to being a great software craftsman is to understand the problem domain
you work within, and value this as much as you value your technical expertise.
Patterns For Understanding The Problem Space Are Useful On All

Projects, Model-Driven Design May Not Be
Many of the strategic patterns of DDD can be used in the creation of any medium to large-scale
business system regardless of the underlying complexity. In fact all of of the strategic patterns
have many benefits before even starting to code. Subdomains can help breakdown complex systems
to aid communication. Context maps reveal integration points between subdomains and different
contexts of the business. However it is sometimes difficult to justify the tactical patterns of applying
the domain model pattern to anything other than a complex or constantly evolving domain.
7.1 Code Is A Product Of DDD Not The Process

The most often asked question on the DDD forums is, Can I see a sample application?. There
are probably many solutions that can be provided that show the end result of a product developed
under a DDD process, however much of the benefit of DDD is not revealed when you only examine
the code artefact. DDD is performed on whiteboards, over coffee, and in the corridors with
business experts; it manifests itself when a handful of small refactorings suddenly reveal a
hidden domain concept that provides the key to deeper insight.
The code artefact is the resulting product of months and months of hard work, however it
only represents the last iteration. The code itself would have been through a number of guises
before it reached what it resembles today. Over time the code will continue to evolve in order
to support the changing business - a model that is useful today may look vastly different to
the model used in future iterations of the product.
If you were to view a solution that has been built following a DDD approach hoping to emulate the
philosophy a lot of the principles and practices would not be experienced and too much empathises
would be placed on the building blocks of the code. Indeed if you were not familiar with the domain
then you would again not find the underlying domain model very expressive.
http://groups.yahoo.com/group/domaindrivendesign.
93
What DDD is not
94
DDD does prescribe a set of design best practices, patterns and building blocks which are
often mistakenly thought as core to applying DDD to a product. Instead think of these design
artefacts as merely a means to an end used to represent the conceptual model. The heart
of DDD lies deep in the collaboration between the development team and domain experts to
produce a useful model.
7.2 DDD Is Not For The Faint Hearted

Realised that agile has one fatal flaw. It still requires motivated, smart people who
care for it to succeed, same as its predecessors - Chris Pitts @thirstybear
DDD is not for everyone, it is certainly not the right fit for every project. In order to gain the
most benefit when following DDD are a complex core domain that will be invested in over time is
required. In addition to an iterative development process and access to domain experts. However
that is not all which is required, there are a number of other skills that you need to succeed at DDD.
To be effective at DDD you need:
Solid design principles required for refactoring
Sharp design sense
A focused, motivated and experienced team
You need disciplined developers who are willing to work with domain experts and understand the
business rather than worry how then can wedge in the latest JavaScript framework into a project.
Remember DDD isnt a silver bullet, just as switching from an upfront waterfall approach to a more
agile/XP project methodology didnt solve all of your software development problems, likewise
opting to follow DDD wont suddenly produce better software. The common denominator in any
successful project is a team of clever people who are passionate about what they are doing
and who care about it succeeding.
Get as much knowledge as you can
Understand the problem, understand the domain, analyse the design and only then decide
how you are going to provide the solution. If you can defer frameworks and platforms for as
long as you can, this will give you more time to decide what it a good fit for your problem.
.
What DDD is not
95
7.3 Ask Yourself: Is It Worth This Extra Complexity?

Dont be too eager to apply the tactical patterns of DDD.
When junior developers learn about design patterns they will try to apply them to every
piece of code that they write. This behaviour is often seen when teams learn about DDD.
They will focus only on the tactical patterns of DDD, blindly applying these patterns to every
project regardless if it is justified. This eagerness to apply a new philosophy without due
consideration as to whether the process is a worthwhile endeavour for the software can lead
to needless complexity where a simple solution would have sufficed.
Beware The Anemic Domain Model

Teams are often too keen to apply the tactical patterns of DDD at the expensive of the domain as
a whole. Trying to create a domain model to suit the needs of every domain scenario will result in
an anemic model , devoid of any behaviour and which will simply resemble a data transfer object.
Any logic for the domain would reside in a myriad of services and procedural code, rather than a
model of the domain.
Not A Solution To Every Problem

DDD is a design philosophy suited to a particular problem space. If your business is not complex or
isnt changing frequently then dont automatically reach for the DDD hammer, remember there are
other better suited tools in your development tool kit. Only focus your modelling efforts and DDD
on the most complex bounded contexts that bring the most value to your customer.
Not all subdomains are complex, some domains or contexts may not even need a fully-fledged
domain model and may just contain data with no business logic that simply requires the basic CRUD
operations. For low complexity contexts favour the use of a CRUD/Active Record/Transaction Script
based application and leave the tactical patterns of DDD for parts of your system that are important
to your customer, that are complex and change frequently.

Only create a domain model if a bounded context is complex and contains rich domain
language
DDD is far more than coding.
You need a smart dedicated team willing to learn about the domain.
You need access to a domain expert. Teams cant reveal deeper insights without them.
http://martinfowler.com/bliki/AnemicDomainModel.html.
What DDD is not
96
Use CRUD for bounded contexts with low complexity. You are not a bad programmer if you
dont have a domain model.
II The Practice: Coding The Strategic

And Tactical Patterns Of DDD
Whats in this part?
Details on the options open for architecting Bounded Contexts

Code examples detailing how to integrate with legacy applications
Techniques for communicating across Bounded Contexts
Implementation patterns for the building blocks of DDD
Best practices for development
97
8 Strategic Patterns of Domain-Driven

Design
98
9 The Building Blocks of

Domain-Driven Design
99
10 Domain-Driven Design Best

Practices
100
III Case Study: Putting Theory And

Coding Patterns Into Practice
Whats in this part?
Working through a complex domain problem to showcase all the practices of DDD
101
11 A Modelling Example
11.1 Case Study
102
Appendix
103
Version History
This book is a work in progress. Here is a list of updates by date:
4th Feb 2013:
Refactor for Deeper Design Insights: Making The Implicit Explicit
104

Practicing DDD

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Practicing DDD

Caricato da

Copyright:

Formati disponibili

Practicing Domain-Driven Design

Practical advice for teams implementing the development

2012 - 2013 Scott Millett

Tweet This Book!

Why You Should Read This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Who Should Read This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Domain-Driven Design In A Nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

How This Book Is Structured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Other Books On Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Theory: Introduction To The Philosophy

The Need For Domain-Driven Design

A Philosophy Over A Framework Or Methodology . . . . . . . . . . . . . . . . . .

Writing Large-Scale Complex Business Software Is Hard . . . . . . . . . . . . . . .

Code Without Organisation Will Rot . . . . . . . . . . . . . . . . . . . . . . . . . .

Understanding Your Problem Space

Knowledge Crunching : Finding The Model . . . . . . . . . . . . . . . . . . . . . .

What Is A Domain Model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Gaining Domain Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Challenges With Upfront Design . . . . . . . . . . . . . . . . . . . . .

Techniques For Creating A Useful Model . . . . . . . . . . . . . . . . . . . . . . . .

Capture Use Cases Of The System . . . . . . . . . . . . . . . . . . . . . . .

Defer The Naming Of Concepts In Your Model . . . . . . . . . . . . . . . .

Look For Existing Models . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Domain Experts: Your Guide To Deeper Understanding In Your Problem Domain . .

Sit With Your Domain Experts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Knowledge Distillation : Breaking Down Large Systems To Find What Is Core . . .

Seeing The Wood In-spite Of The Trees . . . . . . . . . . . . . . . . . . . . . . . . .

Domain Vision Can Reveal What Is Core . . . . . . . . . . . . . . . . . . .

The Core Domain Doesnt Always Have To Be Perfect First Time . . . . . . . . . .

Subdomains Exist In The Problem Space . . . . . . . . . . . . . . . . . . . . . . . .

Without Context We Are Nothing . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multiple Models In A Subdomain . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Shifting Focus From The Project To The Product . . . . . . . . . . . . . . . . . . . .

Less Hast More Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Salient Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Speaking The Language Of Your Domain

The Language Of Domain Experts . . . . . . . . . . . . . . . . . . . . . . . . . . .

Collaborating On An Enhanced Language . . . . . . . . . . . . . . . . . . . . . . .

Enhancing The Language With Discovered Terms . . . . . . . . . . . . . . . . . . .

Working With Concrete Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .

A Language Tied To A Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Salient Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Shaping Your Solution Space

Retaining The Integrity Of Models In Subdomains . . . . . . . . . . . . . . . . . . .

The Challenges Of Maintaining A Single Model: Blurred Responsibility . . . . . . .

Bounded Contexts: Define A Boundary Of Responsibility Around A Model . . . . .

Implementing A Bounded Context . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Importance Of Bounded Contexts . . . . . . . . . . . . . . . . . . . . . . . . .

A Bounded Context Can Cover More Than One Subdomain . . . . . . . . . . . . .

More Than A Single Bounded Context Per Physical Deployment . . . . . . . . . . .

Sizing Your Models And Bounded Contexts . . . . . . . . . . . . . . . . . .

Architectural Patterns Apply To Bounded Contexts Not Systems . . . . . . . . . . .

Understanding The Relationships Between Bounded Contexts . . . . . . . . . . . .

Context Maps Clearly Show Business Process . . . . . . . . . . . . . . . . . . . . .

Bounded Contexts Work Together To Solve Business Problems . . . . . . . . . . . .

Integration Between Bounded Contexts . . . . . . . . . . . . . . . . . . . . . . . .

Modules (aka .Net Namespaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Anti Corruption Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introducing Bounded Contexts Into Legacy Code . . . . . . . . . . . . . . .

Open Host Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Patterns For Team Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Salient Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Complex Core Domains Should Be Based On A Model

The Domain Model: Expressing The Model In Code . . . . . . . . . . . . . . . . . .