Introduction toDomain Driven Design

Ganesh Subramanian22/12/2010

http://sysin.wordpress.comhttp://dynamicquerygen.sourceforge.net

Problem

Diverse Characters to solve one problem Everybody talks in different language Ultimate Result- Delivered solution is brittle

and Fragile

Problem

Everybody who are involved should talk in one LanguageStep 1 : Agree on language terminology and

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

language

Solution

What is DDD? Not a technology or a methodology A way of thinking and a set of priorities,

aimed at accelerating software projects that have to deal with complicated domains

Primary focus on the domain and domain logic

Complex domain designs based on a model.

Domain Driven Design

Traditional Architecture

Presentation Layer

Business Layer

Data Access Layer

Infr

astr

uctu

re

Layer

Layered Architecture

User Interface Responsible for showing information to the user and

interpreting the user's commands Application

Does not contain business rules or knowledge Coordinates tasks and delegates work to domain objects Does not have state reflecting the business situation Interacts with application layer of other systems

Domain Contains business logic and rules Reflects the state of business situationHeart of business software

Infrastructure Provides generic technical capabilities that support the

higher layersPersistence, Sending Emails, libraries, utilities etc…

Layered Architecture (contd…)

Building Blocks

Shopping Cart Application

DDD in Practice

Shopping Cart Application

Shopping Cart Domain Model

Entity A noun with an identity Mutable - State can change over time Can be associated with other entities and value objects Can’t be shared

Value Object A noun without an identity Immutable - State can’t change Can be associated with other entities Can be shared

Aggregate One root entity per aggregate Associated entities can refer to root but not other

entities in the aggregate All operations are done through root

Building Blocks Revisited

Service Has operations that conceptually doesn’t below to an

domain object Stateless Interface is defined in terms of other elements of the

domain model A service can be part of any layer (Application, Domain,

Infrastructure) Factory

Creates the entities and value objects Use only when the entity creation is complex

Repository Collection of entities Takes care of updating an entity Takes care of retrieving an already persisted entity One repository per aggregate root

Building Blocks Revisited (Contd…)

Layers in Shopping cart App

???

Questions