Domain-Driven Design (DDD) is an approach that focuses on modeling a complex domain and problem solving. It emphasizes modeling the domain and domain logic over technical details. When building large, mission critical systems, tactics and strategy in DDD address both tactical and strategic design challenges. To get started, one looks at the business processes, breaks the domain into sub-domains, focuses on a sub-domain with domain experts to develop a shared language, and identifies domain events based on commands and queries.

1. Knowledge Sharing Session
Md. Sadhan Sarker
Software Engineer
Journey to Domain Driven Design

2. 2
Domain-Driven Design is an approach to the development of complex
software. It focus on domain itself and not the technical details.
Primarily on modeling the problem and trying to solve.
When huge, mission critical, n-tier solutions and too big for the human
mind.

3. 3
Tactics and strategy must be combined to
succeed, and DDD addresses both tactical
and strategic design.

4. 4
How Do We Get Started?
- Look at the big picture of the current business process.
- Breaking the domain into sub-domains.
- Focus on sub-domain with domain expert use ubiquitous language
- Creating a bonded context between sub-domain.
- Identity Domain Events based on Commands & Query.
- Shared kernel - any changes should be known and agreed between all
team in every bounded context.
- Focus the domain’s behaviors rather than domain’s state.

5. 5
Big Ball of Mud

6. 6
Context Map
Bounded
Context
Bounded
Context
Bounded
Context

7. 7
?
Customer Order
Buggy Issues
Payment
E-Commerce Application
Context
Team Ubiquitous language &
Bounded Context
Ubiquitous
Language

8. 8
Building Blocks of
A Model Driven Design

9. Layered vs Hexagonal Architecture
- Domain-related code spread tracing is difficult.
- Business rules hard to tracking.
- Automated testing is awkward.
- An object-oriented program, So less Isolation.
9

10. 10
DDD - Entity
“Many objects are not
fundamentally defined by their
attributes, but rather by a thread
of continuity and identity.”
Eric Even

11. 11
DDD - Value Object
As Eric Evans has noted,
"Many objects do not
have conceptual identity.
These objects describe
certain characteristics of
a thing."

12. 12
DDD - Aggregate Root & Root Entity

13. 13
Domain Events
CreateOrder Command
CQRS &
Event Sourcing

14. 14
Domain Events
CreateOrder Command

15. 15
Layers in a Domain-Driven Microservice

16. 16
Continuous Integration

17. Md. Sadhan Sarker
Software Engineer
Thanks! From
Coding is Fun, Enjoy It…!