1. Domain
Driven
Design
2023 © Mother Earth
Radhouane Jrad

2. The Plan
• DDD in General (History, etc.)
• Designing in DDD
• Implementing DDD: Use-Case
• Implementing DDD Principles
• DDD & Horizontal Scalability
• Principles Guiding API Governance
02/23

3. Disclaimer
DDD is a rich, complex, sometimes antagonistic topic. This presentation is an implementation of
DDD and some aspects may differ from other implementations.
The views in this presentation fairly (but not fully) adhere to standard DDD concepts.
03/23

4. Mantra
As a developer, it is your understanding, rather than your knowledge, that becomes software!
Alberto Brandolini
04/23

5. Origins: 2003
05/23

6. How Did We Get to DDD?
Business Model Business Domain
Domain Driven
Design
• Describes core aspects of company’s values
(economic, social, environmental, etc.) & how it
‘lives’ them
• Reflects rationale of a company’s purposes,
processes, markets, products & services, strategies,
infrastructure, operational processes, policies, etc.
Business Strategy
• Defines goals of the company
• Competitive matters: How to fight & compete?
What are our strengths & weaknesses? Where
are market opportunities? Lateral concerns
(social, societal, environmental, etc.)
• Different to Operational Strategy (efficiency, cost
mgmt., etc.)
Corporate Strategy
• Existential matters:
• What business should
we be in?
• What business should
we NOT be in?
• Essentially, 2 types of models:
• Linear (aka Pipes): upstream production &
downstream consumption,
e.g. ink > pen + lid > wholesale
• Networked (aka Platforms): multi-directional
exchange (e.g. Digital Transformation)
• We start getting technical:
• A “simple view” of a “complex Reality (UML)
• Class-based representation of objects being implemented
• Generated through Business Modelling & designed by Business
Analysts.
• Categorises the set of business systems that represent autonomous
units of the business modeled during Business Analysis.
Strategy
Operations
Infrastructure
• Aim is to structure the code and its language to
reflect the Business Domain
• e.g. Class ClaimApplication; + Class Customer +
method approveClaim + method rejectClaim
06/23

7. The Concept of Domain Driven Design
Business Domain
Domain Driven
Design
• We start getting technical:
• A “simple view” of a “complex Reality (UML)
• Class-based representation of objects being implemented
• Generated through Business Modelling & designed by Business
Analysts.
• Categorises the set of business systems that represent autonomous
units of the business modeled during Business Analysis.
• Aim is to structure the code and its language to
reflect the Business Domain
• e.g. Class ClaimApplication; + Class Customer +
method approveClaim + method rejectClaim
06/23

8. When to Use DDD?
07/23

9. Meaningfulness of DDD
08/23

10. DDD Strategic Tools
09/23
Sleeping
Compartment
Engine Room
Logistics
Kitchen
Captain’s Corner
Viewing Deck
Gathering Area

11. DDD Strategic Tools
10/23
Dining Room
Kitchen
Master
Bedroom
Garage
Guests Room
Living Room
Kid’s Room
Master Storage
Storage
Front Lawn
Shower/WC

12. Designing in DDD
11/23

13. Insurance Example
Customer =
Active policies,
historical
policies, MTA
Domain: Policy
Customer =
Open claims,
historical claims,
NCD status
Domain: Claim
Customer =
Name, physical
address, mobile
no.
Domain: Party
DB
API
DB
API
DB
API
12/23

14. Case Study: Integration for Insurance
13/23

15. Policy
Domains Cross-Contamination
14/23
Claims
DGL API
AL API
ACL API
DGL API
AL API
ACL API
Consumer A
Sys. Of.
Rec
X
Claims

16. Policy
Domain Gateway Layer APIs
15/23
Claims
DGL API
AL API
ACL API
DGL API
AL API
ACL API
Consumer A
Sys. Of.
Rec
• DGL API act as gateway to the
domain
• Every domain’s Abstract Layer is
constructed, developed, and
maintained ignoring other domains
• Every domain’s ACL is constructed,
developed, and maintained ignoring
other domains
• Security, Infrastructure,Testing, and
Asset Reusability requirements are
easy to address
• Usually one DGL API per Domain.

17. Domain Gateway Layer APIs
16/23

18. Claims Policy
The Case of a Common System of
Records
17/23
DGL API
AL API
ACL API
DGL API
ACL API
Consumer A
Sys. Of.
Rec
Consumer B
X

19. Claims Policy
Anti-Corruption Layer
17/23
DGL API
AL API
ACL API
DGL API
ACL API
Consumer A
Sys. Of.
Rec
Consumer B
Claim Processes
Need Policy no?
Policy Processes

20. DDD & Horizontal Scalability
18/23

21. Instance A
(1 CPU Unit)
DDD & Horizontal Scalability
19/23
Step 1 Step 2 Step 3 Step 4 Step 5
Instance B
(1 CPU Unit)
Step 1 Step 2 Step 3 Step 4 Step 5
Queues Queues

22. Some Notes:
20/23

23. Principles Guiding API Governance
21/23
Structural Principles
Feedback-Based Design (DSR)
SOLiD:
•Single Responsibility Principle (SRP)
•Open/Close Principle (OCP)
•Liskov, Interface Segregation Principle (ISP)
•Dependency Inversion Principles
Reusability Primacy of Principles
Domain Driven Design
Separation of Concerns
Three-layered Architecture
API-Led Architecture
YAGNI
Minimise Coupling
KISS
Git-based Version Control
O-Auth based Security
C-back with JWT
Asset exposure
(Marketplace)
IPaaS
(Managed Services)
API Catalogue
Logging
Smart Endpoints, Dumb Pipelines Asynchronous vs. Synchronous
Queues vs. EDA vs. Pub/Sub
Driving Principles
Technological Baseline
Security By Design
Horizontal vs. Vertical Scalability
Singular Technology
Integration Inventory
Load Balancers
REST vs. SOAP
Component Based Statelessness

24. API Building Blocks
22/23
Domain
Driven
Design
API-Led
Design
Pattern
Horizontal-
First
Scalability
REST-first ,
JSON-first
Integration
iPaaS
Security
By
Design
Product-
based
Reusability; Evolvability; Extensibility;
Security; Cost-Effectiveness;
Auditability; Clarity;
Simplicity/Simplification…

25. Thanks
23/23
LinkedIn: Radhouane Jrad
Questions?
2016 2013 2003
Some Good
Reads: