domain driven design

Lalit Kale

e-Zest Solutions Ltd.

Domain Driven Design

Problem

Problem- Characters Involved

ProblemDiverse Characters to solve one problemEverybody talks in different languageUltimate Result- Delivered solution is brittle

and Fragile

Everybody who are involved should talk in one Language

Step 1 : Agree on language terminology and definitions

Step 2: Call on the language expertStep 3 : Use Business model to device the

language

Solution

Domain: “A field of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in that field “.

Driven: Focused on

Domain Driven Development

Domain: “A field of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in that field “. = Problem Domain

Domain Model: The domain model is a rigorously organized and selective abstractions of knowledge’

Domain Driven Development

Traditional Architecture

Presentation

Data Access (DAL) Infr

ast

ructu

re/

Uti

lity

/L

ibra

ry

Business Layer

DDD ArchitectureUser Interface

Filesystem

Services

etc

Database

Application Services

M

Domain Services

Tests

Infrastr

ucture

Domain Model

DDD ArchitectureUser Interface

Filesystem

Services

etc

Database

Application Services

M

Domain Services

Tests

Infrastr

ucture

Domain Model

DDD Jargon

• Conceptual

• Ubiquitous Language

•Bounded Contexts•Persistence

Ignorance•Refactoring•Command Query

Separation (CQS)• When to use DDD• When NOT to Use

DDD

• Patterns

•Entities•Value Objects•Aggregate Roots•Object Creation

Patterns•Repository•Specification•Domain Services•Modules•Domain Events•State Machines

DDD Fundamentals

encapsulate with

MODEL-DRIVEN

DESIGN

express model with

isolate domain with

encapsulate with

ENTITIES

VALUE OBJECTS

LAYERED

ARCHITECTURE

AGGREGATES

REPOSITORIES

act as root of

SMART UI

X

FACTORIES

encapsulate with

express model with

encapsulate with

mutually exclusivechoices

access with

maintain integrity with

access withSERVICES

express model with

DDD Fundamentals-EntityObjects that have a distinct identity that runs through time and different representations. You also hear these called "reference objects".

Entities are usually big things like

DDD Fundamentals-Value ObjectsA small simple object, like money or a date range, whose equality isn't based on identity.

Value Objects are usually small things (Hidden concepts in system) like

DDD Fundamentals- Aggregate RootsAn Aggregate comprises of an intimately associated group of Entities and Value Objects

Aggregates are treated as a single unit for the purpose of persistence, and references are only allowed to the Aggregate Root

DDD In Practice

Without DDD

With DDD-Code Flows

Promotes high cohesion and low coupling Easy to test domain components Business (domain) logic is isolated from non-

domain and infrastructure code Adding/changing services does not influence

the domain or other services.Everybody talks on same terms

Advantages