craig berntson [email protected] twitter: @craigber
TRANSCRIPT
DOMAIN DRIVEN DESIGN FOR THE
AVERAGE APPLICATION
Craig Berntson
www.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: [email protected]
Copyright 2007 - 2009, Craig Berntson. All rights reserved