DOMAIN DRIVEN DESIGN FOR THE

AVERAGE APPLICATION

Craig Berntson

www.craigberntson.com

craig@craigberntson.com

Twitter: @craigber

WHO AM I? Microsoft MVP since 1996 Magazine and book authoring Speaker at developer events across US

and in Canada, Germany, and Czech Republic

WHAT WE’LL TALK ABOUT A brief history of application design What is Domain Driven Design Dive into Domain Driven Design Find out that you already do much of

this

DESIGN IN ANCIENT TIMES

DESIGN IN NOT SO ANCIENT TIMES

Object Oriented

Programming

Business rules

N-tier designDistributed apps with

COM+

Copyright 2007 - 2009, Craig Berntson. All rights reserved

3-TIER ARCHITECTURE

•Presents info to user and interprets user commands

•Business rules often stored here

UI (Presentation)

•Thick layer that holds majority of business rules

•Heart of application

Business

•Accesses the database

•Business rules often stored here

Data

DESIGN IN MORE RECENT TIMES

AGILE Individuals and interactions over

processes and tools Working software over comprehensive

documentation Customer collaboration over contract

negotiation Responding to change over following a

plan

Source: http://www.agilemanifesto.org/

OBJECT DESIGNA behavioral approach mandates the assignment of responsibilities first. Only when you are satisfied with the distribution of responsibilities among your objects are you ready to make a decision about what they need to know…Behavior is the only criterion we use to differentiate among objects.

- Dr. David West

Source: Object Thinking

OBJECTS VS. DATA“When data is the center piece of your object, you assign data to objects before saying what they do. Descriptions of data don’t tell you squat about your objects.”

- Rocky Lhotka

Source: http://www.theserviceside.net/articles/content/businessobjects/businessobjects.

html

DOMAIN TIERThis is the work that this application needs to do for the domain you’re working with. It involves calculations based on inputs and stored data, validation of any data that comes from the presentation, and figuring out what data source logic to dispatch, depending on commands received from the presentation.

Logic that is the real point of the system.- Martin Fowler

Source: Patterns of Enterprise Application Architecture

DESIGN TODAY

WHAT IS DDD?When you remember that DDD is really just “OO software done right”, it becomes more obvious that strong OO experience will also stand you in good stead when approaching DDD.

Source: http://www.developerfusion.com/article/9794/domain-driven-design-a-step-by-step-guide-part-1

CONTROLLING COMPLEXITYThere are many things that make development complex. But the heart of this complexity is the essential intricacy of the problem domain itself…The key to controlling complexity is a good domain model…A good domain model can be incredibly valuable but it’s not something that’s not easy to make. Few people can do it well and it’s very hard to teach.

Source: Martin Fowler – Forward to Domain Driven Design

DOMAIN EXPERTS Start with the people inside the domain Domain is often huge.

Focus on domain where software will run

Create an abstraction ormodel of the domain

THE UBIQUITOUS LANGUAGEDefine the vocabulary that is used by the Domain Experts and use it in your design

ICD-9 APGICD-10 APRDRG APCDx PxHCPCS CPT

MODELING Noun / Verb Paper Whiteboard Post-It® Notes

LAYERED ARCHITECTURE

•Presents info to user and interprets user commands

UI (Presentation)

•Thin layer that coordinates application activity.

•No biz logic or state of biz objects, but can hold state of an application task

Application

•Heart of the software.

•Info about the domain.

•Holds state of biz objects

Domain

•Persists biz objects.

•Supporting layer for layers.

•Provides communication between layers.

Infrastructure

OBJECTS, PATTERNS, AND SUCH Entities Value Objects Services Modules Aggregates Factories Repositories

ENTITIES An object that has an identity Consider them from the beginning of

design Be alert to mistaken identity

VALUE OBJECTS Used when we’re interested in the

attributes of an object, not what object it is

Golden rule: Immutable Created with a constructor, and never

changed during their lifetime Keep them thin and simple Can contain references to other Value

Objects or to an Entity

VALUE OBJECTS

Customer

CustomerIDNameStreetCityState

Customer

CustomerIDNameAddress

Address

StreetCityState

SERVICE An object that does not have state Provides functionality across objects Characteristics of a Service:

Operation refers to a Domain concept, but cannot be mapped to an Entity or Value Object

Operation refers to other objects in the Domain

Operation is stateless

MODULES Used to organize related concepts to

reduce complexity Increases cohesion and reduces

couplingCommunicationalFunctional

Have well defined interfaces Module names become part of the

Ubiquitous Language

ASSOCIATIONS 1-1, 1-M, Bidirectional How to simplify

Remove non-essential associationsAdd constraints to reduce multiplicityTransform bidirectional into unidirectional

AGGREGATES Used to simplify associated objects Definition: A group of associated objects

which are considered as one unit with regard to data changes.

A boundary separates objects on the inside form those on outside

Has a single root – an Entity Outside objects can only access the root Root Entity has global identity and

maintains the invariants Inside Entity has local identity

FACTORIES Encapsulate the knowledge necessary

for object creation Create new objects from scratch or

reconstitute old objects GoF

Factory MethodAbstract Factory

Entity Factories vs. Value Object Factories

WHEN NOT TO USE A FACTORY Construction is not complicated Creation of object does not include

creation of other objects Client is interested in the

implementation The class is the type (no hierarchy)

REPOSITORIES Stores references to globally accessible

objects (Remember that the Root of an

Aggregate is globally accessible) If an object is requested and it doesn’t

exist, it is created Implementation is closely linked to the

Infrastructure, but the Interface is Domain

REFACTORING Continue refactoring the design Start with a shallow model, refactor as

you gain insight Breakthrough can cause lots of

refactoring – do it in small steps

FURTHER READING Domain Driven Design

Eric Evans Domain Driven Design Quickly

Abel Avram Applying Domain-Driven Design and

PatternsJimmy Nilsson

.NET Domain-Driven Design with C#Tim McCarthy

REVIEWData first design Behavior firstN-tier design LayersBusiness rules Domain layerDistributed apps SupportedAgile SupportedBusiness Language

Ubiquitious language

Analysis & Design Modeling

REVIEWEntities Most not usingValue Objects

New to most of us

Services Many usingModules Multiple VS projectsAggregates OOP/Design PatternsFactories OOP/Design PatternsRepositories New to most of usRefactoring Refining design

QUESTIONS? Web: www.craigberntson.com Twitter: @craigber Email: craig@craigberntson.com

Copyright 2007 - 2009, Craig Berntson. All rights reserved