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

About… InterKnowlogy (www.InterKnowlogy.com) MGB 2003 About… InterKnowlogy (www.InterKnowlogy.com) 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.

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

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.

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.

Demo: Organizing Domain Logic

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.

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.

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

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

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

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

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!

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

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

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!

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

Demo: Creating a DDD Framework

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

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

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.

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

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!

Demo: Using Specifications

This is DDD…

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

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

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

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

Tim McCarthy, InterKnowlogy MGB 2003 Tim McCarthy, InterKnowlogy Get the Demos & PPT at: Blogs.InterKnowlogy.com/TimMcCarthy More info on InterKnowlogy: www.InterKnowlogy.com Contact me: Tim McCarthy E-mail: TimM@InterKnowlogy.com Phone: 760-930-0075 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.