1.
Re-engineering
an Enterprise
with
Domain Driven Design
RAJU K
XEBIA

2.
About Raj
• Enterprise Agile Coach
• Professional ScrumTrainer
• Xebia Agile Consulting and Transformation - North Americas Practice Lead

3.
Time for a poll…
If your current Enterprise is bit older (more than 15+ years) –
What type of IT Systems do you see?
A. Individual Silos supporting Line of Businesses
B. Well organized, productized IT Systems focused on BusinessValue

4.
Something familiar?
• Enterprises – which are bit older – are designed and operated in this way:
User experience/UI
Applications
APIs, Business Logic
Platform & Ops
Infrastructure
Line of Business
User experience/UI
Applications
APIs, Business Logic
Platform & Ops
Infrastructure
Line of Business
Shared
services:
Architecture,
App
Sec,
SRE
etc.

5.
Key Challenges…
• Bureaucracy
• Power dynamics between Leaders
• Lot of sunk costs in maintenance
• Slow response times
• Not easy to scale
• Huge hidden costs of SW/HW licensing
https://www.youtube.com/watch?v=whi2vzAc8VY

6.
Better Future State
• A re-engineered Enterprise – ready to take on the world
BusinessValue Stream
Infra &
Platform

7.
Conway’s law…
• Any organization that designs a system, (defined broadly), will produce a design whose structure is a copy of
the organization's communication structure.
-- Melvin Conway, 1968

8.
Domain driven design
• Domain-driven design (DDD) is a major software design approach,[1] focusing on modeling
software to match a domain according to input from that domain's experts.[2]
• Under domain-driven design, the structure and language of software code (class names, class
methods, class variables) should match the business domain. For example, if software processes loan
applications, it might have classes like loan application, customer, and methods such as accept offer
and withdraw.
• Domain-driven design is predicated on the following goals:
• placing the project's primary focus on the core domain and domain logic;
• basing complex designs on a model of the domain;
• initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual
model that addresses particular domain problems.
https://en.wikipedia.org/wiki/Domain-driven_design

9.
DDD – Bounded context
• This is one of the most valuable constructs within DDD.
• It provides the mechanism to break up large and complex systems into discrete
pieces.
• You will need to think of each as being its isolated from its neighbor, and loosely
coupled via events & services
Image source: BoundedContext
(martinfowler.com)

10.
DDD – Bounded context
• One of the goals of Domain Driven Design, is to deliver software that directly reflects
the common language of a given domain.
• Let's use Making a car to illustrate the concepts of DDD.
• Our illustration is going to cover the process of making a car.

11.
Arrange these in correct order
• Can you arrange these steps in making a car in correct order?
Procuring various
components
Assembling
Transporting to a
dealer
Delivering to a
Dealer
Painting

12.
High level flow
• Lets start with the high-level flow Procuring various
components
Assembling
Transporting to a
dealer
Delivering to a
Buyer
Painting

13.
Buyer
Dealer
Transporter
High level flow
• The Domains of making a car – from a car perspective
Manufacturing
Plant

14.
Buyer
Dealer
Transporter
Vocabulary…
• Notice how each Domain has its own unique language and vocabulary
Manufacturing
Plant
Product Load Business Need or
Status Symbol

15.
Buyer
Dealer
Transporter
Vocabulary…
• Each domain has its own understanding
of the “car”
• These can lead to Silos/Monoliths…
Manufacturing
Plant
• Bill of Material
• Assembly Line
• Configuration
• Final
Destination
• Route
• Weather
conditions
• Other vehicles
in load
• Down
payment
• Payment terms
• Delivery Dates
• Exchange/
Trade-in
• Mileage
• Maintenance
costs
• Accessories
• Installments if
any

16.
Domain and Context
• To bring all these into a common understanding, we have to set the context boundaries
• Each domain will expose its services so other domains can consume the same – creating
a BusinessValue Stream perspective
Buyer
Dealer
Transporter
Manufacturing
Plant
Product is
the “car”
Load is the
“car”
Business is
the “car”
Need or
Status Symbol is
the “car”
• GetBoM()
• RoadTest()
• NSRTest()…
• GetLoad()
• PlanLoad()
• Track()…
• SalesOrder()
• Customer_Account
_Creation()
• Process_Order()…
• Do_PaperWork()
• Do_PDI()
• Take_Delivery()…

17.
DDD through Event Storming
Event
Something that has happened
<noun> <verb>, e.g. order submitted
Command
An action started by a policy in response
to an Event
Capability
Component
A component that is part of a business
capability within the Domain. This
becomes a micro-service.
System
An External system or service which is
outside the Domain
Data
The information that represents an Event
Policy
The reaction to an Event:
When <event> then <command>
Sub
Process
A sub process which is reused or defined
in a separate event storm
Question or
Assumption
A question or assumption that requires
follow up

18.
An example
Event
Something that has happened
<noun> <verb>, e.g. order submitted
A New order at Manufacturing Plant
Command
An action started by a policy in response
to an Event
Raw materials are procured
Capability
Component
A component that is part of a business
capability within the Domain. This
becomes a micro-service.
GenerateVIN Label, Sticker
System
An External system or service which is
outside the Domain
Notify Government Agencies
Notify the Dealer and/or Buyer
Data
The information that represents an Event
Car status is “in Transit”
Policy
The reaction to an Event:
When <event> then <command>
Wrap the car to protect from damages
Sub
Process
A sub process which is reused or defined
in a separate event storm
Get Route approvals/permits etc.
Question or
Assumption
A question or assumption that requires
follow up
Vehicles are secured during Transport

19.
Our flow…
Process payment
service
Preferred
Delivery
date
I want to buy a car
Offer pre-delivery
inspection
Buyer
Name,
address,
contact
Send
Vehicle
and Buyer
details
Car is
shipped
Book a car
Car
received
by Dealer
Car
booked
Support preferred
delivery date of
Buyer
Process payment
service
Licensing
details
This emerging pattern is defining the Bounded Context
for the Capability Component
This is our first Deliverable Artifact: It is a map of the Domain's processes.
MV/RTO Database
Data Policy Command
Capability
Component
(Aggregate)
Event
External system
Legend:

20.
After the storm…
• A Capability Component now has a Bounded Context. The Bounded Context is
revealed when you remove the Events and Policies Leaving behind the Components,
Data, and Commands
Update
Dealer
Order Update
Service
Get
Payment
Assemble
the car
Procure
Raw
material
Shipping
Payment
Order
Car Details,
Configuration
• The Commands will become API resources or
Message subscriptions
• The Data entities will become the Data Model
• The Capability Component is the Logic
(Policies) and State (Data Model) necessary to
turn Commands into Events
This is our Second Deliverable
Artifact: Identify the Components and their
Bounded Contexts

21.
… the end game !
• With the Bounded Context defined, a Capability Component becomes a Micro-Service
that we can code and deploy!
Update
Dealer
Order Update
Service
Get
Payment
Assemble
the car
Procure
Raw
material
Shipping
Payment
Order
Car Details,
Configuration
Now the real work begins.
The Event Storm got us to the Bounded Context.
So, now we can define our API or Message
Contracts, the underlying Logic, and derive the
Data Model.

22.
Capability Component
(Microservices)
Business Capability
Product/Service
Domain
Final Example
Car Manufacturer
Make the car
Orders
Order Management
Payment
processing
Shipping
Load Planner
Route Planner
Dealers
Sales & Delivery
Inventory
Management
Service
Service Orders
Spares and
Accessories
Training
Domain - L1
Product - L2
Business capability - L3
Capability Component
- L4
Business capability –
L3
Capability
Components – L4
Product - L2
Business capability - L3
Capability Component
- L4
Business capability –
L3
Capability
Components – L4
Products & ServicesTaxonomy
Services (e.g. Microservice)

23.
Execution Plan
Domain
Products / Services
Microservices aka Capability components
Domain 1
Capability 1
Capability 2
Capability 3
Domain 2
Capability 4
Capability 5
Capability 6
etc….
MVP Increment
Capability 1
Capability 2
Capability 3
Next Increment
Capability 4
Capability 5
Capability 6
etc….
Next Increment
Capability 4
Capability 5
Capability 6
DDD
1a – Establish business process & Identify Domains and
boundaries
1b – Event storm on domains and define capabilities
1c – Breakdown domain / capabilities into candidate
Microservices
Decomp
2a – Analyze current applications and decompose them to
capabilities
2b – Map capabilities to DDD identifies (Step 1)
services
Build 3b – Initiate development on MVP (First Increment)
3c – Create execution roadmap for application based
on capabilities
2c – Identify MVP scope (Initial set of capabilities)
3d – Next Increment planning
3a – Kick-off with dependent domain owners
Iterate

24.
Agility at the core of DDD
• XP Practices –
Collective Code
ownership, Refactoring
etc.
• Short 2-week Sprints
within a quarter
increment cycle –
frequent inspect and
adapt opportunities
• MVP Concepts helping
Business to re-engineer
and reap Agility
benefits
• BusinessValue Streams
providing a unified view
of the Enterprise –
ease in planning,
budgeting and
execution

25.
Any Questions?

26.
ThankYou