An overview about Domain Driven Design (DDD) in Software Architecture

1. Domain Driven Design:
Fundamentals
By Hannah Farrugia

2. Lesson 1
 What is DDD?
 What makes it valuable?
 Goal definition
 DDD principles
 Modelling paradigms
 Onion architecture

3. What is
Domain Driven
Design?
• A software design tool and a way of thinking that
bases domain modelling on a business driven
concept
• A design that strives on communication between
domain experts and software architect(s)
• A centralised knowledge-rich design
• An iterative, adaptive process of discovery and
challenges that lead to learning and continuous
improvement

4. Why pursue
DDD?
• Focuses on the core problems that the system is
expected to solve
• Beneficial for complex domains and business
areas
• Manages to organise and simplify object models
in ways that are strategic and focussed
• Creates a clear separation between areas
• Encourages clear and common understanding
between stakeholders
• Based on Agile principles

5. Goal definition :
• To simplify the domain complexities
through a ubiquitous language, define
system boundaries that focus on specific
business problems and keep a focus on
the business logic residing in the core
domain.

6. DDD Principles
As Eric Evans says:
A domain model is not a particular diagram; it is the idea that
the diagram is intended to convey. It is not just the
knowledge in a domain expert's head; it is a rigorously
organized and selective abstraction of that knowledge. A
diagram can represent and communicate a model, as can
carefully written code, as can an English sentence.
Uncovers key business drivers through constant questioning
Unification of jargon that leads to a Ubiquitous Language
Works with Collaboration/Experimentation/Adaptation
Depicts the agreed knowledge
Boundaries will be defined… And redefined

7. • In object-oriented programming,
the open/closed principle is applied.
This states that "software entities should be
open for extension, but closed for modification";
that is, such an entity can allow its behaviour to
be extended without modifying its source code.
• Every method should be either a command
that performs an action, or a query that
returns data to the caller, but not both. In other
words, asking a question should not change
the answer. More formally, methods should
return a value only if they are referentially
transparent and hence possess no side effects
-Meyer, Bertrand
Object Oriented Design
and Command Query Responsibility
Segregation
Agile supports DDD
• Individuals and interactions over
processes and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a
plan
-Agile Manifesto
Iterative, Agile
Creating designs that can easily be
prototyped to involve stakeholders earlier
and demonstrate how the model ties into the
functional software:
• This provides feedback at the initial
stages of the design
• It surfaces gaps from requirement
analysis or design
• Stakeholders feel more involved in
moulding the final version.
Prototyping
Modelling paradigms:

8. Summary:
• DDD is a way of thinking that creates a design based
on the business needs of the organization
• Its value is derived from the simplification of
complexities in the domain
• The goal is to focus on business contexts individually
and align knowledge to one source of truth
• DDD is an iterative process that refines the model
through learning
• Goes hand in hand with CQRS and OOD, makes it
easy to prototype during iterations

9. Domain Services
Onion Architecture definition :
Domain
Model
Application Services
Domain Services
User Interface •Normally there is one onion
architecture per bounded
context
•Outer layers depend on internal
ones, therefore the dependency
flow goes inward
•The infrastructure resides
outside of this layer

10. Domain Services
Onion Architecture definition :
Domain
Model
Application Services
Domain Services
User Interface
Triggers for
business logic
Core objects and
business rules
• Ports
• Adapters
• Interfaces with ORM,
search engines,
messaging
interfaces
The layer that
surfaces the
functionality to the
user

11. Subdomain
Example
High level requirements specification
Notifications for an existing Payments
System
Based on specific
business rules
Different mailing
options [Email and
SMS]
Customisable
message content
Notification tracking
Logging and
reporting

12. Strategic
Design
What we did, what we do
Our amazing products
Our awesome ideas
Marketing data and our estimation
1
Before starting
Introduction
2About us
3Our portfolio
4New proposal
5Analysis
Eric Evans - Domain Driven Design : Tackling complexity in the heart of
software

13. • Ask for the definition of the
important words, but most
importantly understand how
they form part of the business
process
• Complexities will come out of
the conversation with domain
experts
• Define what feeds into the
requirements, the output that
is expected from them and any
constraints that you should be
aware of

14. Context Maps
• Maps the system areas and relationships between them
• Each one has its own language, but can be shared or coupled with
other contexts
• Can be based on team structures
• Boundaries are created between contexts to create focus on specific
areas
• Bounded contexts =/= sub domains
• Bounded contexts within the scope of DDD, refer to the domain
layer, although they can still have an independent infrastructure

15. Some more
Requirements
• Fraud detection system –
Create a notification for every
case that is deemed fraudulent
• Notify the customer when their
transaction is a chargeback
• Notify the customer when their
spending reaches the daily
limit
• Send the user a notification
when they activate their portal
account

16. The organization
behind it
• The bigger teams within the
organization split the
responsibilities between the
Operations and Customer
Support, the account
management and boarding
team
• Exceptions are handled by the
dispute management team
• Fraud and analytics are a
small team that have a large
responsibility

17. Object
identificatio
n
Triggers for our notifications are based on:
• Amounts per card brand
• The cases created by the fraud system rules
• The status of a chargeback and
• The status of the customer web account

18. What about the ubiquitous language?:

19. Summary:
• DDD is typically designed based on an onion
architecture for loose coupling between domains,
applications and the infrastructure
• Event storming is a great way to focus on the business
behind the domain and to gather information in a
structured way
• Requirements for our business case, constraints and
rules that apply
• Evan’s strategic design map
• Context map and business case contexts
• Requirements from an object point of view
• Translators can be needed to protect the ubiquitous
language of a domain

20. Examining bounded contexts

21. Tactical Design
What we did, what we do
Our amazing products
Our awesome ideas
Marketing data and our estimation
1
Before starting
Introduction
2About us
3Our portfolio
4New proposal
5Analysis
Eric Evans - Domain Driven Design : Tackling complexity in the heart of
software

22. Shared Kernels
•Based on collaboration
•Changes will need every party involved
•They should be kept to a minimum
•Shared Kernels will probably be the
result of either a core or generic domain
•Technology might require rework if there
are conflicts in existing contexts

23. Entities
Questions you can ask to test if an object is an entity:
Do two similar objects (like a person), need to be
distinguishable?
 If you have two instances of the same object , can
one replace the other?
Is there a unique identifier for the object?
Entities are represented by
continuity and identity
Multiple instances of an entity still
point to the same conceptual
identity
Defining an entity depends on the
business context
Most importantly, remember that entities are mutable

24. Aggregate Roots
• Entities within the same aggregate are cohesive
 An encapsulated structure with a group of
entities
The root can be referenced by objects
outside of the boundary, but other objects
within the boundary cannot be referenced

26. Value
Objects
SEARCH
• VOs describe entities. They have no conceptual identity, and yet an
entity is not quite complete without these descriptors
• VOs are interchangeable
• They can be passed in a message when being transferred from one
object to another
• They are Immutable, so they cannot be changed except by full
replacement
• They normally form a conceptual whole
• There are school of thoughts that classify types differently

28. Summary:
• Tactical design incorporates structuring domain details
in entities, value objects and aggregates
• Entities have their own ID and are mutable.
• Aggregates hold groups of objects inside of them –
remembering that objects that are not part of the root,
but part of the aggregate, cannot be referenced by
objects outside of the aggregate.
• Value objects describe entities and are immutable

29. Invariants
• A type of validation
• Maintained by an entity
• Consistency rules satisfied whenever data
changes
• Involved in relationships between members of an
aggregate
• An object within an aggregate must satisfy all of
the invariants

30. Anti
Corruption
Layer
The Power of PowerPoint - thepopp.com30
 Helps prevent corruption of information
 It's necessary if another model is structured
differently
 IT interacts with different bounded contexts,
foreign systems, legacy apps or databases.
 In practice, there may still be the need to talk
to a monolith system,
 An ACL normally carries design patterns like
facades, adapters and translators

31. • Domain events are a way to describe
activities/state changes that occur in the system,
• Objects within the domain that raise the event
don’t worry about what happens after the event is
raised
• Domain events require handlers .
• Handlers can be thought of as listeners
• Events always represent things that occurred in
the past
• Typically, a domain event will output the
timestamp of when the event occurred.
• Domain events do not have any side effects
Domain Events

32. • Factories create and reconstitute complex objects. They
act as an interface that create instances of complex
objects, entities and aggregates.
• The outcome of an operation can entail the creation of an
object.
• The creation of objects is therefore handled through a
factory that can create aggregates and enforce their
invariants. (for implementation information refer to Factory patterns in Gamma et al.
1995)
• Repositories can be thought of as an in-memory
collection interface (with more elaborate querying
capability).
• Acquiring references to existing domain objects can be
done via query methods
• Repositories store and are used to find persistent objects
• Their purpose is to keep the domain model business
focussed.
Factories and Repositories in DDD

33. Specification
s*
SEARCH
• A specification pattern states the constraints on the state of an object
• Used to test if an object satisfies certain criteria.
• Sometimes, complex business rules do not fit the responsibility of a
particular entity or value object.
• To solve this dilemma, the rule can be implemented as a specification
object or objects (including AND, OR, NOT etc).
• When a factory creates an object, it can also take the responsibility of
configuring its specification.
*This term was coined by Evans and Fowler. Detailed information can be found in this document
https://www.martinfowler.com/apsupp/spec.pdf

34. .
Service
implementation
• Domain Services - A service can be defined as the
realisation of a process. A domain service is "an
operation to the model as a standalone interface" that "is
not a natural responsibility of an Entity or a Value Object".
• Application Services - These interact with other systems,
listen for incoming messages and decide whether or not
to use an infrastructure service.
• Infrastructure Services - Here, an infrastructure-related
action will happen.
Services
Domain Services
Domain
Model
Application Services
Domain Services
User Interface
Notification system

35. • Geared towards database requirements,
not business requirements
• A domain model that is simply reduced to
getting and setting, holding little to no
business logic and not really reflecting
the events and behaviours that trigger or
impact business rules
• A model where the business rules are
stored in the application (or other) layers
• Anemic models result into lots of time
wasted into mapping the objects to the
persistence layer
https://martinfowler.com/bliki/AnemicDomain
Model.html
Anemic Domain Model
• Domain experts will probably not be well-
versed with the DDD framework.
• Keep yourself updated with DDD
(references available in the references
slide)
Being influenced by the
current system
• The process for DDD is meant to be
agile.
• Taking a big bang approach will go
against the iterative model
Taking a big bang
approach
DDD Anti-Patterns
Keep
Calm
and
Think.

36. Lessons Learnt
1.DDD is situational:
• System complexity makes a difference
• Will the system need frequent changes?
• You're always trying to solve a specific problem.
• Vernon’s scorecard:
http://www.informit.com/articles/article.aspx?p=1944876&seqNum=2 (scroll down)
2. Rebuilding and changing at the same time should be avoided:
• Lost focus
• Reengineer first, DDD last
• Changing is expected
• DDD assumes that the business use cases are static
3. If you're changing an existing system to DDD:
• Take the bubble approach - "Getting Started with DDD When Surrounded by Legacy
Systems " - Evans http://domainlanguage.com/ddd/surrounded-by-legacy-software/
• Keep previous test cases

37. References and Resources
Type Source Why it's useful When you should read it
Book Domain-Driven Design: Tackling
Complexity in the Heart of Software
From
https://www.amazon.com/Domain-Driven-
Design-Tackling-Complexity-
Software/dp/0321125215/ref=sr_1_1?keyw
ords=Domain-
Driven+Design%3A+Tackling+Complexity+i
n+the+Heart+of+Software&qid=155913458
7&s=books&sr=1-1
This is the DDD bible If you haven't read it, you should read it now. (Otherwise you can use
it like a DDD- Dictionary).
Book implementing Domain-Driven Design by
Vaughn Vernon
From
https://www.amazon.com/dp/0321834577
/ref=emc_b_5_i
A very good book that
explains DDD, it's
good to get some
additional information
You've read Evan's book, but you're looking for different explanations
of the same things
15 essays in one
pdf
https://leanpub.com/ddd_first_15_years There's some eye-
opening ideas here,
and some really
genuine recollections
of DDD experiences
You've started a DDD project and realised that DDD has some
utopian concepts. Reading about other people's challenges will make
things easier to process.
Website https://martinfowler.com/tags/domain%20dr
iven%20design.html
If there are some
DDD concepts that
are unclear,
explanations here are
very grounded
You need a break from books, we all do. A bite-size article is a nice
break from books.
So you want more?, Check out this mega list (it isn’t mine, but I've used it) - it's pretty updated!:
https://github.com/heynickc/awesome-ddd

38. Summary:
• Invariants – Conditions that are always true and never
change
• ACL – Protect your domain from corruption
• Domain Events – specific to domain layer and do not
have any side effects
• Factories and repositories – These take care of the
creation and storage of objects
• Specifications – A place where complex business rules
that don’t fit in one specific object can reside
• Services – Domain, application and infrastructure
services
• Anti patterns
• Common lessons