Transcript Slide 1
Craig Berntson
www.craigberntson.com
[email protected]
Twitter: @craigber
Microsoft
MVP since 1996
Magazine and book authoring
Speaker at developer events across US and in
Canada, Germany, and Czech Republic
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
Object
Oriented
Programming
Business
rules
N-tier design
Distributed
apps with
COM+
Copyright 2007 - 2009, Craig Berntson. All rights reserved
UI
(Presentation)
• Presents info to user and
interprets user commands
• Business rules often stored here
Business
• Thick layer that holds majority
of business rules
• Heart of application
Data
• Accesses the database
• Business rules often stored here
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/
A 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
“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
This 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
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-guidepart-1
There 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
Start
with the people inside the domain
Domain is often huge.
Focus on domain where
software will run
Create an abstraction or
model of the domain
Define the vocabulary that is used by the
Domain Experts and use it in your design
ICD-9
ICD-10
DRG
Dx
HCPCS
APG
APR
APC
Px
CPT
Noun
/ Verb
Paper
Whiteboard
Post-It®
Notes
UI
(Presentation)
Application
Domain
Infrastructure
•Presents info to user and interprets user
commands
•Thin layer that coordinates application activity.
•No biz logic or state of biz objects, but can hold
state of an application task
•Heart of the software.
•Info about the domain.
•Holds state of biz objects
•Persists biz objects.
•Supporting layer for layers.
•Provides communication between layers.
Entities
Value
Objects
Services
Modules
Aggregates
Factories
Repositories
An
object that has an identity
Consider them from the beginning of design
Be alert to mistaken identity
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
Custome
r
CustomerID
Name
Street
City
State
Custome
r
CustomerID
Name
Address
Address
Street
City
State
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
Used
to organize related concepts to reduce
complexity
Increases cohesion and reduces coupling
Communicational
Functional
Have
well defined interfaces
Module names become part of the Ubiquitous
Language
1-1,
1-M, Bidirectional
How to simplify
Remove non-essential associations
Add constraints to reduce multiplicity
Transform bidirectional into unidirectional
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
Encapsulate
the knowledge necessary for
object creation
Create new objects from scratch or
reconstitute old objects
GoF
Factory Method
Abstract Factory
Entity
Factories vs. Value Object Factories
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)
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
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
Domain
Driven Design
Eric Evans
Domain Driven Design Quickly
Abel Avram
Applying Domain-Driven Design and Patterns
Jimmy Nilsson
.NET Domain-Driven Design with C#
Tim McCarthy
Data first design
N-tier design
Business rules
Distributed apps
Agile
Business Language
Analysis & Design
Behavior first
Layers
Domain layer
Supported
Supported
Ubiquitious language
Modeling
Entities
Value Objects
Services
Modules
Aggregates
Factories
Repositories
Refactoring
Most not using
New to most of us
Many using
Multiple VS projects
OOP/Design Patterns
OOP/Design Patterns
New to most of us
Refining design
Web:
www.craigberntson.com
Twitter: @craigber
Email: [email protected]
Copyright 2007 - 2009, Craig Berntson. All rights reserved