domain-driven design from theory to practice

23
Domain-driven design from theory to practice Artur Trosin

Upload: jerzy

Post on 23-Feb-2016

62 views

Category:

Documents


0 download

DESCRIPTION

Domain-driven design from 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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Domain-driven design from theory to practice

Domain-driven designfrom theory to practice

Artur Trosin

Page 2: Domain-driven design from theory to practice

Before start

Page 3: Domain-driven design from theory to practice

Why DDD nowadays?

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

Page 4: Domain-driven design from theory to practice

Why DDD?

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

Page 5: Domain-driven design from theory to practice

DDD benefits?

• Reduced complexity• High maintainability• Continuous collaboration and feedback• Translations are reduced to minimum

Page 6: Domain-driven design from theory to practice

Domain - particular field of knowledge

Page 7: Domain-driven design from theory to practice

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

technical one.

Page 8: Domain-driven design from theory to practice

Domain Driven Design is based on models.

Page 9: Domain-driven design from theory to practice

Atom Model

Page 10: Domain-driven design from theory to practice

Even Music has a Model

Page 11: Domain-driven design from theory to practice

The key to controlling complexity is a good domain model.

Page 12: Domain-driven design from theory to practice
Page 13: Domain-driven design from theory to practice

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”

Page 14: Domain-driven design from theory to practice

We need common view and language!

Business DomainDomain Model

&Ubiquities Language

Software Development

Page 15: Domain-driven design from theory to practice

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

Page 16: Domain-driven design from theory to practice

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.

Page 17: Domain-driven design from theory to practice

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

Page 18: Domain-driven design from theory to practice

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

Page 19: Domain-driven design from theory to practice

Building blocks

Page 20: Domain-driven design from theory to practice

Classic Layering

UI

Business Entities

Data Access

DB

Record Sets orData Sets or

POCO orPOJO

Page 21: Domain-driven design from theory to practice

DDD recommended-Layering

UI

Application

Domain

Infrastructure

Domain Model

Service LayerUI

Infrastructure

Serv

ice G

etaw

ays

Page 22: Domain-driven design from theory to practice

Organizing Domain Logic Patterns

Complexity of Domain Logic

Effortto enhance

Domain Model

Table ModuleTransaction Script

Source : PoEAA by Martin Fowler

Page 23: Domain-driven design from theory to practice

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