Domain-driven designfrom theory to practice

Artur Trosin

Presentation for: Software as Craft 2009, 14-16 May

Before start

Why DDD nowadays?

• Automation of various business domains• High competition for a market place• Growing business complexity• Complexity becomes inevitable

Why DDD?

• Accidental complexity is bad• DDD is OO done right• Semantics over technology• Is discovered and NOT invented

DDD benefits?

• Reduced complexity• High maintainability• Continuous collaboration and feedback• Brings to front the “Core Domain Knowledge”• Translations are reduced to minimum

Domain - particular field of knowledge

Complexity of most software projects is understanding the business domain and not a

technical one.

Atom Model

Domain Driven Design is based on models.

Even Music has a Model

The key to controlling complexity is a good domain model.

Martin Fowler

They are two different worlds!

Business Domain(business experts)

Software Development(development team)

We need to bring them together(business domain & technical)

Successes depends on “how well you bring them together”

We need common view and language!

Business DomainDomain Model

&Ubiquities Language

Software Development

Domain Model - is a rigorously organized and selective abstraction of the (Business) Domain knowledge.

Ubiquitous Language - A language structured around the domain model and used by all team members to connect all

the activities of the team with the software.

Ubiquitous Language

Technical aspectsof design

Technical terms

Technical design patterns

S.O.L.I.D design principles

Domain Model Terms

DDD Patterns

Bounded Contexts

Business termsdevelopers don’t

understand

Business termseveryone uses that

don’t appear in design

Candidates to fold into model

Collaboration

Business Domain

Domain Model&

Ubiquities Language

Software Development

Software

Produce

Based on

Domain Experts and Developers produce Model

Reflected in

Direct mapping between business domain concepts and software artifacts

Building blocks

Classic Layering

UI

Business Entities

Data Access

DB

Record Sets orData Sets or

POCO orPOJO

DDD recommended-Layering

UI

Application

Domain

Infrastructure

Domain Model

Service LayerUI

Infrastructure

Serv

ice G

etaw

ays

Organizing Domain Logic Patterns

Complexity of Domain Logic

Effortto enhance

Domain Model

Table ModuleTransaction Script

Source : PoEAA by Martin Fowler

Mutually exclusivechoice

Model-Driven Design

Services

Entities

Value Objects

LayeredArchitecture

Smart UI

Repository

Aggregates

Factories

Express model with

Express model with

Express model with

Isolate domain with

Access with

Access with

Encapsulate with

Encapsulate withEncapsulate with

Encapsulate with

Maintain integrity with

Act as root of

X

Modules

Express model with

A model expressed in software with: Life Cycle of domain object controlled by:

Associations

Country

Person

President

*

Country

Person

President

*

Country

Person

President

*

Period

Entities

• An object defined primarily by its identity and not its attributes

• Could be a person, a customer, an order, etc.• Not all objects have meaningful identities…• In some systems, a class may be an ENTITY, in

others maybe not

Value Objects

• Represent an aspect of the domain with NO conceptual identity

• Use when you care about what something is, not who they are

• Simple, immutable objects• NOT is same thing as a DTO [Fowler PoEAA]

Services

• An operation offered as an interface that stands alone in the model

• Does not fit into any of the objects in the model• Stateless• To be used judiciously (do not turn your app into

a Transaction Script)• Use when an operation is an important domain

concept

Modules

• Is larger grain of modeling and design• A method of organized related concepts• Low coupling and high cohesion• Communications mechanism.• Could be Administration, Invoicing, Reports,…

Aggregates

• A cluster of associated objects that is treated as a conceptual whole

• Define consistency boundaries• A unit for the purpose of data changes• Is controlled by root

Factories

• Shifts complicated object creation to FACTORY• Enforce invariants• Decouple clients and hide creation details

Repositories

• Provide illusion of an in-memory collection• Provide a simple model for obtaining

persistent objects• Decouple domain model from persistence

technology• Communicate design decisions about object

access• IS NOT just DAO with CRUD

Cargo Sample

Collecting Basic requirements

• Book cargo in advance• Track key handling of customer cargo

Cargo •Tracking Id

Route Specification

•Origin Location•Destin Location

Leg •Load Location•Un-Load Location

Itinerary