1. Craig Berntson www.craigberntson.com craig@craigberntson.com Twitter: @craigber

2.  Microsoft MVP since 1996  Magazine and book authoring  Speaker at developer events across US and in Canada, Germany, and Czech Republic

3.  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

5. Object Oriented Programming Business rules N-tier design Distributed apps with COM+ Copyright 2007 - 2009, Craig Berntson. All rights reserved

6. 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

8.  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/

9. 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

10. “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

11. 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

13. 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

14. 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

15.  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

16. Define the vocabulary that is used by the Domain Experts and use it in your design ICD-9APG ICD-10APR DRGAPC DxPx HCPCSCPT

17.  Noun / Verb  Paper  Whiteboard  Post-It® Notes

18. 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

19.  Entities  Value Objects  Services  Modules  Aggregates  Factories  Repositories

20.  An object that has an identity  Consider them from the beginning of design  Be alert to mistaken identity

21.  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

22. Custome r CustomerID Name Street City State Custome r CustomerID Name Address Address Street City State

23.  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

24.  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

25.  1-1, 1-M, Bidirectional  How to simplify  Remove non-essential associations  Add constraints to reduce multiplicity  Transform bidirectional into unidirectional

26.  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

27.  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

28.  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)

29.  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

30.  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

31.  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

32. Data first designBehavior first N-tier designLayers Business rulesDomain layer Distributed appsSupported AgileSupported Business LanguageUbiquitious language Analysis & DesignModeling

33. EntitiesMost not using Value ObjectsNew to most of us ServicesMany using ModulesMultiple VS projects AggregatesOOP/Design Patterns FactoriesOOP/Design Patterns RepositoriesNew to most of us RefactoringRefining design

34.  Web: www.craigberntson.com  Twitter: @craigber  Email: craig@craigberntson.com Copyright 2007 - 2009, Craig Berntson. All rights reserved