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