1. Domain-Driven Design Tim McCarthy Principal Engineer, InterKnowlogy
MGB 2003
Domain-Driven Design
Tim McCarthy
Principal Engineer, InterKnowlogy
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

2. About… InterKnowlogy (www.InterKnowlogy.com)
MGB 2003
About…
InterKnowlogy (
Tim McCarthy, Principal Engineer
Custom App Dev / Consulting / Software Engineering Firm headquartered in Carlsbad, CA
Microsoft Gold Partner managed in SoCal and Redmond
Design, Architect, Build and Deploy enterprise class applications
Industry Experts:
90% of the company is published
Microsoft® .NET Application development for 5+ years!
Microsoft® .NET Smart Client pioneers / industry leaders
Information Worker Solutions
Integration / Messaging, B2B / B2C, Wireless / Mobility
Microsoft® SharePoint, Microsoft® BizTalk® Web Services, Microsoft® Active Directory®, Security, SSO, Authorization, Authentication
Solutions on the emerging Microsoft servers
Largest Client: Microsoft
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

3. Agenda Organizing Domain Logic What is DDD?
Why Domain-Driven Design (DDD)?
DDD Definitions/Patterns
When is DDD appropriate?

4. Organizing Domain Logic
MGB 2003
Organizing Domain Logic
Transaction Script
Domain Model
Table Module
One of the most important, yet often forgot, aspects of enterprise applications is the domain logic. These are the business rules, validations, and calculations that operate on the data as it is brought into an information system or displayed by it. For simple database filing systems there is often little or no domain logic. However for many systems there is often quite complex domain logic, and this logic is subject to regular change as business conditions change.
Transaction Script – a procedure that takes the input from the UI, processes it (validations, calculations, etc.), stores data in a data store (usually a database), and invokes operations from other systems. Most business applications can be thought of as a series of transactions. A transaction may view some information as organized in a particular way, another will make changes to it. Each interaction between a client system and a server system contains a certain amount of logic. In some cases this can be as simple as displaying information in the database. In others it may involve many steps of validations and calculations.
A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper. Each transaction will have its own Transaction Script, although common subtasks can be broken into sub-procedures.
Domain Model – instead of having a routine that has all of the logic for a user action, each object takes a part of the logic that’s relevant to it. Incorporates behavior and data. At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful entity, whether as large as a corporation or as small as a single line on an order form.
The advantage of the domain model is that the logic needed for any particular operation is loosely coupled across the objects rather than being contained in a single method. This pattern tends to view the application as a set of interrelated objects.
Table Module - A single instance that handles the business logic for all rows in a database table or view. A Table Module organizes domain logic with one class per table in the data-base, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model (116) is that, if you have many orders, a Domain Model (116) will have one order object per order while a Table Module will have one object to handle all orders.
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

5. Choosing the Right Approach
MGB 2003
Choosing the Right Approach
Building an object-oriented Domain Model is a popular approach to organizing domain logic. It works particularly well with complex domains. It's downside is that it is difficult to do well. These patterns describe how to think about building and structuring a rich domain model, as well as how to recognize and overcome the real-world obstacles that too-often prevent people from employing the modeling principles they know
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

6. Demo: Organizing Domain Logic

7. MGB 2003
What is DDD?
Good-ole object-oriented design, but with some design rules
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

8. Why Domain-Driven Design (DDD)?
MGB 2003
Why Domain-Driven Design (DDD)?
Most development time is still spent writing plumbing code instead of business logic
Typically, the UI will change a LOT more than the business logic
The model is a great tool for communication between developers and users
.NET has good support for it!
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

9. Ubiquitous Language
Common terms between business experts and development team
Use the language in your code
Namespaces
Class, property, method, variable names

10. Communicating the Language
Create whiteboard drawings
Favor whiteboarding over Visio
Use digital camera to capture, then paste into Word
Use Visual Studio class diagrams for core parts of the domain
Code and diagram are kept in sync
No wasted time diagramming, your diagram is the code

11. Definition: Entities An object defined primarily by its identity
Not its attributes
Could be a person, a customer, an order, etc.
Not all objects have meaningful identities…
In some systems, a class may be an ENTITY, in others maybe not

12. Definition: Value Objects
Represent an aspect of the domain with NO conceptual identity
Use when you care about what something is, not who they are
Same thing as a DTO [Fowler PoEAA]
Simple, immutable objects

13. Definition: Aggregates
A cluster of associated objects treated as a unit for the purpose of data changes
They have a root and a boundary
Boundary = what is inside the AGGREGATE
Root = single ENTITY inside the AGGREGATE
Most important concept to understand in modelling!

14. Aggregate Rules The root ENTITY has global identity
ENTITIES inside the boundary have local identity
Nothing outside the AGGREGATE boundary can hold a reference to anything inside, except to the root ENTITY
Objects in the AGGREGATE can hold references to other AGGREGATE roots
…a few more

15. Definition: Services
An operation offered as an interface that stands alone in the model
Does not fit into any of the objects in the model
Stateless
To be used judiciously (do not turn your app into a Transaction Script)
Use when an operation is an important domain concept

16. Pattern: Repository Provide access to AGGREGATE roots
Represents all objects of a certain type as a conceptual set (usually emulated)
Behaves like a collection, e.g. Add(), Remove()
Persistence Ignorance!

17. Pattern: Layered Supertype [Fowler 475]
Type that acts as the supertype for all types in its layer, i.e. a base class!
Factors out common features, such as handling the identity of ENTITIES
Example: a common ID property
Helps eliminate duplicate code

18. Demo: Creating a DDD Framework

19. Pattern: Specifications - Problem
You need to select a subset of objects based on some criteria, and to refresh the selection at various times
You need to check that only suitable objects are used for a certain role
You need to describe what an object might do, without explaining the details of how the object does it, but in such a way that a candidate might be built to fulfill the requirement

20. Pattern: Specifications - Definition
A predicate that determines if an object meets certain criteria
Explicitly separates the statement of how to match a candidate from the candidate object that it is matched against
States a constraint on the state of another object, which may or may not be present
Keeps the rules in the domain layer!
The rules themselves become objects

21. Pattern: Specifications - Solution
Create a specification that is able to tell if a candidate object matches some criteria. The specification has a method isSatisfiedBy (candidate) : Boolean that returns "true" if all criteria are met by the candidate.

22. Pattern: Specifications - Implementation Types
Hard-coded
Code the selection criteria into the isSatisfied method as a block of code
Parameterized
Create attributes in the specification for values that commonly vary. Code the isSatisfiedBy method to combine these parameters to make the test
Composite
Create a particular form of interpreter for the specification. Create leaf elements for the various kinds of tests. Create composite nodes for the and, or, and not operators

23. Uses of Specifications
Validating an object against a constraint
Select objects from a collection
Specify the creation of a new object to fit some need
Building to order – you define the specs, the builders build to your spec!

24. Demo: Using Specifications

25. This is DDD…

26. When is DDD Appropriate
“If an unsophisticated team with a simple project decides to try a model-driven design with layered architecture, it will face a difficult learning curve. ... The overhead of managing infrastructure and layers makes very simple tasks take longer. Simple projects come with short time lines and modest expectations.”
Domain-Driven Design by Eric Evans, p76

27. Resources
[Evans]: Domain-Driven Design: Tackling Complexity in the Heart of Software, Evans, Addison-Wesley (2003)
[Fowler]: Patterns of Enterprise Application Architecture, Fowler, Addison-Wesley (2003)
[Nilsson]: Applying Domain Driven Design and Patterns: using .NET

28. Looking for Outstanding Developers
Application Development Practice
.NET 2.0 and .NET 3.0
ASP.NET 2.0 and ASP.NET AJAX 1.0
WinForms 2.0 / Windows Presentation Foundation
ASMX / Windows Communication Foundation
BizTalk
Windows Workflow Foundation
SQL Server

29. Looking for Outstanding Developers
Information Worker Practice
SharePoint 2003 / 2007
Office 2003 / 2007
SQL Analysis Services
SQL Reporting Services

30. Tim McCarthy, InterKnowlogy
MGB 2003
Tim McCarthy, InterKnowlogy
Get the Demos & PPT at:
Blogs.InterKnowlogy.com/TimMcCarthy
More info on InterKnowlogy:
Contact me: Tim McCarthy
Phone: x205
About Tim McCarthy
.NET Architect/Dev Lead/Trainer
Author / Speaker
MCSD, MCSD.NET, MCDBA, MCT,
IEEE CSDP
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.