Domain-driven design

(c) 2015-16, No reproduction without permission
Domain Driven Design
Vikas Hazrati
Knoldus Software

What
Eric Evans is the author of
"Domain-Driven Design:
Tackling Complexity in
Software," Addison-Wesley
2004.

What
Eric Evans is the author of
"Domain-Driven Design:
Tackling Complexity in
Software," Addison-Wesley
2004.
We have it in the library !

Why
Your prime goal is to understand the business,
all terms that customer uses and how he models
the domain.

Problem
Technology and Business mismatch

What is software
Software design is an art, and like any art it
cannot be taught and learned as a precise
science, by means of theorems and formulas.

Application
Software provides solutions to real business
problems
The business processes being automated is the
domain of the software.

Metaphor
Developers in general have a myopic view
They start viewing the car as a huge collection of
parts which need to fit together, but a car is
much more than that. A good car starts with a
vision. It starts with carefully written
specifications.
Software cannot be started with just writing code

Developers confused further
What is the difference between Software Design
and Code Design

Software Design vs Code Design
Software design is like creating the architecture
of a house, it’s about the big picture.
On the other hand,
Code design is working on the details, like the
location of a painting on a certain wall.
Difficult to change later
Relatively easier to fix

Understanding Domain
Is essential
The best way to do it is to make software a
reflection of the domain.
Software needs to incorporate the core concepts
and elements of the domain, and to precisely
realize the relationships between them.

Understanding Model
Person reading code should be able to
understand the domain.
Selective abstraction of the domain is a Model. It
is an internal representation of the target
domain.

How much to keep?
Domain has too much information but we need
to be selective for our Model.
For ex. for a core Banking software, we need
person's name but not his pet information.

Communication

Communication
We need to create ways to express it, to
communicate it with others
There are different ways to do that.
One is graphical: diagrams, use cases,
drawings, pictures, etc.
Another is writing. We write down our vision
about the domain.

Communication – Software Devs
●
The developers have their minds full of classes,
methods, algorithms, patterns, and tend to
always make a match between a real life
concept and a programming artifact.
●
They want to see what object classes to create
and what relationships to model between
them.
●
Think in terms of inheritance, polymorphism,
OOP, etc

Communication – Domain Experts
They know about their specific area of expertise

Serious Issues
When team members don’t share a common
language for discussing the domain
Domain experts use their jargon while technical
team members have their own language tuned
for discussing the domain in terms of design.

Need for a common language !

How?
What language is it going to be? The developers’
language? The domain experts’ language?
Something in between?
A core principle of domain-driven design is to
use a language based on the model. Use the
model as the backbone of a language

Team uses this common language in all
communications, &
code. It is used in speech, diagrams, white
boarding sessions, client calls etc.
This is called the Ubiquitous Language.

Ubiquitous Language
●
Does not come out easy
●
Experiment with alternate expressions
●
Refactor, rename as the understanding grows
●
Resolve confusion in all forms of
communication
●
Change in the language should become a
change in the model

How to create a Ubiquitous
Language
●
Watch out for NOUNS in the language used
by the domain experts
●
Each NOUN could potentially become a part
of the model and could be implemented as a
class

Nouns
1)The teacher told the student that a person should
always be loyal.
2)People with perseverance will be successful in life.
3)I bought a new pen at the drugstore across the street.
4)The man said to the policeman that he had not seen
the accident.

Nouns
always be loyal.
teacher, student, person
the accident.

Nouns
always be loyal.
people, perseverance, life
the accident.

Nouns
always be loyal.
pen, drugstore, street
the accident.

Nouns
1)The teacher told the student that a person should always be
loyal.
pen, drugstore, street
4)The man said to the policeman that he had not seen the
accident.
man, policeman, accident

How to keep improving
Ubiquitous Language?
●
Make diagrams that help visualize the model

How?
●
In the code, method names, variable names
should communicate the domain model
●
Assertions of the test should specify what is
expected as per the model

Model
Any domain can be expressed in many models
and any model in multiple possible code
implementations

Analysis Model
The analysis model is the result of business
domain analysis, resulting in a model which
has no consideration for the software used for
implementation.
Since this model is devoid from the software
considerations, it does not work well in real
world.
We would avoid this model

MDD

Components of Model Driven Design

Layered Architecture
Each Layer is cohesive and depends on the layer below it
All code related to domain in one layer and isolated from others
Domain layer does not know how to store itself, show itself

Entities
●
Have an identity which stays the same
throughout the lifecycle of the system
●
The attributes can change but identity
continues
●
Ex Person in the system or Account in a bank

Value Objects
●
Tracking and creating identity comes with a cost
●
Entity cannot be reused across different
operations where identity matters
●
Situations where we are not interested in the
object but the attribute that it holds
●
Without identity objects can be easily created
and discarded
●
Value objects are immutable and can be shared

Value Object
●
For instance, address object could be a value
object and can be shared across entities
●
Value object can contain other value objects
and entities as well

Services
Represent Behaviour

Different kind of services
●
Application Service
●
Domain Service
●
Infrastructure Service

●
Application Service
●
Domain Service
●
Infrastructure Service - ???

●
Application Service
●
Domain Service
●
Infrastructure Service - focused encapsulating
the “plumbing” requirements of an application;
usually IO concerns such as file system access,
database access, email, etc.

Domain and Application Service
●
Domain - Domain services are expressed in terms of
the ubiquitous language and the domain types, i.e. the
method arguments and the return values are proper
domain classes.
●
Application - All logic concerning the application
workflow. Used by external consumers to talk to your
system (think Web Services). If consumers need access
to CRUD operations, they would be exposed here.
Takes commands from the User Interface Layer and
translates these commands to use case invocations on
the domain layer

Modules
●
Modules are used as a method of organizing
related concepts and tasks in order to reduce
complexity
●
Using modules in design is a way to increase
cohesion and decrease coupling
●
Module names should be part of Ubiquitous
Language

3 Main Domain Patterns
Aggregate
Factory
Repository

Aggregates
●
Defines object ownership and boundaries
●
An Aggregate is a group of associated objects
which are considered as one unit with regard to
data changes.
●
Each aggregate has one root which is an Entity
and is the only object accessible from outside
●
There can be other aggregate objects and
entities in a root but to the external world they
are available only through the root.

Aggregates
●
External world cannot directly change other objects
in aggregate. They only talk to root and can request
root to make changes
●
If root is deleted all other objects are deleted as
well
●
Root can pass transient references of internal
objects to external world by passing copies of Value
Objects. Any operation that external world does on
VO does not matter as it is not referenced back

What is the Aggregate Root here?

Factories
●
Deal with object creation
●
Abstracts the external world from the
knowledge of how to create the object
●
In real life, it is like we are given plastic,
rubber, metal, silicon, and we are building our
own printer – We would rather call a factory
method to build the printer

Factories
●
It is important for creation process to be
atomic. It cannot be half done
●
Used normally for complex constructions
●
Not needed if all attributes required for
creation of object can be passed in the
constructor

Repositories
●
Encapsulates all the logic needed to obtain
object references

Repositories
●
Set of methods to retrieve objects

Relation between factory and
repository

Summing it up

Example
Flipkart has your order.
You can track your order, see order details, view
order delivery status. Review or return the
product

Entity

Entity
Status Change

Entity
Value Object

Entity
Value Object
Domain Event

What could be the Aggregate Root?

Entity
Value Object
Domain Event
Aggregate
root

Repositories are one per Aggregate Root, for
example there woud be a Repository called
OrderRepository

What services would you put in domain and which
one in application?

Domain services are expressed in terms of the
ubiquitous language and the domain types, i.e.
method arguments and the return values are
proper domain classes.
Sometimes, only the service trait is part of the
domain layer, but the implementation (how the
service does it) is part of the infrastructure layer.
Likewise, repository traits are part of the domain
layer, but the implementations are not.

Application services are responsible for driving
workflow and coordinating transaction
management
They also provide a high-level abstraction for
clients to use when interacting with the domain.
These services are typically designed to define or
support specific use cases.

Sample Architecture

Architecture Components
Interface
Holds everything that interacts with external
systems. It handles interpretation, validation and
translation of incoming data. It also handles
serialization of outgoing data, such as HTML or
XML across HTTP to web browsers or web service
clients, or DTO classes and distributed facade
interfaces

Application
The application layer is responsible for driving the
workflow of the application, matching the use cases at
hand. This layer is well suited for spanning transactions,
high-level logging and security.
The application layer is thin in terms of domain logic - it
merely coordinates the domain layer objects to perform
the actual work.

Domain
The domain layer is the heart of the software, and this is
where the interesting stuff happens. There is one package
per aggregate, and it contains entities, value objects,
domain events, a repository interface and sometimes
factories.
The core of the business logic, and domain event handling
happens here.

Infrastructure
Infrastructure consists of everything that exists
independently of our application: external libraries,
database engine, application server, messaging backend
and so on
Consider code and configuration files that glues the other
layers to the infrastructure as part of the infrastructure
layer.

Bounded Context
As you try to model a larger domain, it gets
progressively harder to build a single unified
model. Different groups of people will use subtly
different vocabularies in different parts of a large
organization

Bounded Context
Bounded Contexts have both unrelated concepts (such
as a support ticket only existing in a customer support
context) but also share concepts (such as products and
customers).

Bounded Context
●
A Bounded Context is not a Module
●
A Bounded Context provides the logical
frame inside of which the model evolves
●
Ecommerce – User details, User Behavior,
Analytics and Reporting could be different
contexts

Preserving Model Integrity

Context Map
●
A Context Map is a document which outlines
the different Bounded Contexts and the
relationships between them

Shared Kernel
Reduces duplication of effort

Customer Supplier
Example, Analytics module is dependent on the
shopping subsystem.
Analytics is the customer for data which is
supplied by the shopping module

Anti-corruption Layer
●
Allows the model to remain sane inspite of
external influences

Summary of Ways
●
Published Language : the interacting BCs agree on a
common a language (for example a bunch of XML
schemas over an enterprise service bus) by which they
can interact with each other;
●
Open host service: a BC specifies a protocol (for
example a RESTful web service) by which any other BC
can use its services;
●
Shared kernel : two BCs use a common kernel of code
(for example a library) as a common lingua-franca, but
otherwise do their other stuff in their own specific way;

Summary of Ways
●
Customer/supplier : one BC uses the services of another
and is a stakeholder (customer) of that other BC. As such it
can influence the services provided by that BC;
●
Conformist : one BC uses the services of another but is not
a stakeholder to that other BC. As such it uses "as-is"
(conforms to) the protocols or APIs provided by that BC;
●
Anti-corruption layer : one BC uses the services of another
and is not a stakeholder, but aims to minimize impact from
changes in the BC it depends on by introducing a set of
adapters – an anti-corruption layer.

Example Requirements
●
A searchable catalog of Freelancer must be provided
●
The new solution must allow do store the different
Communication Channels available to contact a
Freelancer
●
A searchable catalog of Projects must be provided
●
A searchable catalog of Customers must be provided
●
The Timesheets for the Freelancers under contract
must be maintained

The whole model seems to be more a kind of
Entiy-Relationship-Diagram instead of a software
model.
Where is the business logic?

Let's break it down into Subdomains

Patterns
Strategic Tactical

Strategic Patterns
●
Domain, and Subdomains: Sphere of knowledge. A Domain can be split into
Subdomains if it is too large. The Domain is usually known as the problem
space.
●
Bounded Context: A Bounded context should be aligned with a Domain or a
Subdomain. There is one Ubiquitous Language applied within a Bounded
Context. A Bounded Context is usually the solution space, where we design
our software or business solution.
●
Context Map: A Context Map displays the alignment of Domains,
Subdomains and their Bounded Contexts. A Context Map also shows
dependencies between Bounded Contexts. Such dependencies can be
upstream or downstream. Dependencies show where integration patterns
should or must be applied.

Tactical Patterns
●
Entity
●
Value Object
●
Aggregate
●
Domain Events
●
Service
●
Repository
●
Modules
●
Factory

Subdomains
●
Identity and Access Management Subdomain
●
Freelancer Management Subdomain
●
Customer Management Subdomain
●
Project Management Subdomain

1
2
3 4
Generic

Adding Behavior

Adding Behavior
Freelancer moved to new location
Which subdomain do we need to target?

Either call
Setters – bad idea

Domain Service
Value Object

End to End call

Application Service
● Security
● Transaction boundary
● Technical Services
Any client
● Mobile
● Web
● Angular etc
Domain behavior

Architecture

Context Integration
How contexts talk to each other
● Synchronous Communication
●Asynchronous Communication

Synchronous
A Customer can only be deleted if there is no
Project assigned
There is communication between 2 subdomains.
Customer and Project

Trait present in
customer
Domain Service
Any service which
cannot independently
belong to one domain
and spans across
multiple domain objects

Infrastructure,
Rest endpoints defined
here

Asynchronous
Once a timesheet is entered, customer must be
billed
The 2 events above need not be synchronous.
Here we use the Domain Events

1
2
3
Events stored in
local event store
Picked up by
JMSAdapter
Or it could be an
Akka fire and
forget

Usually events should be modeled as
idempotent operations. If the same event
is executed multiple times, it should give the
same result without causing side effects

Exercise
KnolX Management System
●
Ability to create and manage KnolX sessions
●
View KnolX sessions on a monthly calendar
●
Link videos and slides to KnolX Session
●
Search for a session
●
Search for all sessions by a Knolder
●
Ability to rate a session

References
1) Implementing DDD
2) DDD – Eric Evans
3) http://dddsample.sourceforge.net/
4)http://www.infoq.com/articles/ddd-in-practic
e
5)http://blog.mirkosertic.de/architecturedesig
n/dddbuildingblocks

Domain-driven design

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Domain-driven design

Similar to Domain-driven design (20)

More from Knoldus Inc.

More from Knoldus Inc. (20)

Recently uploaded

Recently uploaded (20)

Domain-driven design