domain-driven design from theory to practice

Domain-driven designfrom theory to practice

Artur Trosin

Before start

Why DDD nowadays?

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

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• 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.

Domain Driven Design is based on models.

Atom Model

Even Music has a Model

The key to controlling complexity is a good domain model.

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

DDD : navigation map

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