DOMAIN-DRIVEN DESIGN

Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s CLASSROOM

BITS PilaniOff-Campus Work-Integrated Learning Programmes

AGENDA

� Why Domain-Driven Design?

� Core Patterns

ERIC EVANS SPEAKS

� Eric Evans, the author of Domain-Driven Design, has been programming and designing systems for 25 years

� He asserts that for most software projects, the primary focus should be on the domain and domain logiclogic

� “Domain-driven design flows from the premise that the heart of software development is knowledge of the subject matter and finding useful ways of understanding that subject matter. The complexity that we should be tackling is the complexity of the domain itself -- not the technical architecture, not the user interface, not even specific features. This means designing everything around our understanding and conception of the most essential concepts of the business and justifying any other development by how it supports that core.”

From http://domaindrivendesign.org/articles/blog/evans_eric_ddd_and_mdd.html

“The goal of domain-driven design is to create

better software by focusing on a model of the

domain rather than the technology.”domain rather than the technology.”

DDD LEADS TO MODEL-DRIVEN DESIGN

� Domain-Driven Design leads to Model-Driven

Design since developers capture their knowledge

of a domain in models

� In particular

� A model-driven design is software structured around � A model-driven design is software structured around

a set o domain concepts

� E.g.: A model-driven design for a UI framework is

one in which UI concepts, such as windows and

menus

� Teams who embrace model-driven design are aware

that a change to the code IS a change to the model

(and vice versa)

MODEL-DRIVEN DESIGN BENEFITS DDD

� The model and its implementation shape each other

� The link between model and code makes the model relevant and ensures that the work spent on analysis is not wasted

� The model creates a language used by all team membersmembers

� The language spreads domain knowledge throughout a team

� It allows developers to speak to domain experts (e.g. users) without translation

� The model is distilled knowledge

� Analysis is hard; we need to capture the information we get from it

� The model is the team’s agreed-upon way of structuring domain knowledge and distinguishing the elements of most interest

TACKLING COMPLEXITY

� The heart of software is its ability to solve domain-related problems

� for its users� Software functionality either solves a domain-related problem or performs a domain-related task� All other features support these two goals

� When a domain is complex, it becomes difficult to � When a domain is complex, it becomes difficult to accomplish this� To be successful, developers must steep themselves in the domain

� Problem: Most developers are not interested in this!� Domain work is messy and demands a lot of knowledge not necessarily related to computer science

� Developers enjoy quantifiable problems that exercise their technical skills!

� But, domain complexity has to be tackled head-on by developers or they risk irrelevance!

CRUNCHING KNOWLEDGE

� Domain modeling requires processing (crunching)

knowledge

� In the same way that financial analysts crunch numbers

� While speaking with domain experts, a domain

modeler will

� try one organizing idea (set of concepts) after another

� create models, try them out, reject some, transform others

� Success is achieved when the modeler has created a

set of abstract concepts that makes sense of all the

details provided by the domain experts

� Domain experts are a critical part of the process

� Without them, developers tend to create models with

concepts that seem naive and shallow to domain experts

INGREDIENTS OF EFFECTIVE MODELING

� Bind the model and the implementation

� As a model is developed, create rapid prototypes that

test the domain

� These prototypes contain primarily domain concepts

� no UI, no persistence, no infrastructure

� Develop a knowledge-rich model

� The objects of your model should have behavior and

may follow rules

� The model should not be just a data schema (think

class diagram) but should express behavior,

constraints, etc. that help solve domain related

problems

KNOWLEDGE-RICH DESIGN

� Models capture more information than just the

“classes” of a domain

� it goes beyond the “find the nouns and verbs”

heuristic of some object-oriented models

� In particular, models capture behavior, business

activities, and business rules (policies,

constraints, etc.)

EXAMPLE: MODELING BUSINESS RULES

The association might look like this:� The association might look like this:

EXAMPLE: OVER BOOKING CARGO?

� A standard practice in the shipping industry is to

accept more cargo than a particular ship can

carry on voyage

� This is know as “overbooking” and is used because

there are typically always last-minute cancellationsthere are typically always last-minute cancellations

� One way of specifying the overbooking policy is via a

percentage of the ship’s total capacity ~ 10%

EXAMPLE: HIDDEN KNOWLEDGE PROBLEM

� Overbooking policy is not reflected in our model

� The policy has been recorded in a requirements

document and hidden away inside one method in our

application

� Domain-Driven Design recommends making that � Domain-Driven Design recommends making that

knowledge a part of the model: change the model,

change the code (and vice versa)

EXAMPLE: CONTINUED,

� Our code would now look like this:

� and the OverBookingPolicy class would have a method:

PROBLEM

� It is not practical for software developers to

become domain experts, or for domain experts to

become software developers.

� Both parties can easily become confused by the � Both parties can easily become confused by the

plethora of undefined terminology and acronyms.

� Solution: Ubiquitous Language.

UBIQUITOUS LANGUAGE

UBIQUITOUS LANGUAGE

“A language structured around the

domain model and used by all team

members to connect all the activitiesmembers to connect all the activities

of the team with the software.”

AGENDA

� Why Domain-Driven Design?

� Core Patterns

PROBLEM

� Domain-Driven Design is overkill.

� Very little domain logic.

� Mostly data entry / retrieval.

� Short deadline.

� Prototype or a “one off.”� Prototype or a “one off.”

� Low-level of modeling skill.

� Solution: Smart UI

SMART UI

� Put the business logic in the user interface.

� Create a separate user interface for every application function.

� Store all data in a shared relational database.� Store all data in a shared relational database.

� Program in 4GL languages and use rapid prototyping tools; Java/C# is overkill.

PROBLEM

� Lots and lots of complicated domain logic.

� Long-lived project lifetime.

� Ambitious goals.

High-level of modeling skill.� High-level of modeling skill.

� Solution: (Domain) Model-Driven Design.

MODEL-DRIVEN DESIGN

� Uses a single model for both analysis (to understand

the domain) and design (to implement the software).

� Requires an iterative development process and

continuous refactoring.continuous refactoring.

� Developers are also modelers.

This is hard.

ASIDE: THE MODEL DEBATE

What is the relationship between the

domain model and the source code?

“Tightly relating the code to an underlying model “Tightly relating the code to an underlying model

gives the code meaning and

makes the model relevant.”

PROBLEM

� There is too much crap in my domain logic.

� I wish I could pull all of this crap out so that the

model is easier to see and change.

Solution: Layered Architecture� Solution: Layered Architecture

Crap is a scientific term.

LAYERED ARCHITECTURE

USER INTERFACE LAYER

� Presents information to the user and interprets

the user's commands.

APPLICATION LAYER

� Defines the application services: what the software actually does for the user.

� Orchestrates the domain objects to implement these application services.

� Has state reflecting the progress of a service call � Has state reflecting the progress of a service call in execution.

� This layer is kept thin.

DOMAIN LAYER

� Represents concepts of the business, information

about the business situation, and business rules.

� Maintains state reflecting the business situation.

This layer is the heart of business software.� This layer is the heart of business software.

INFRASTRUCTURE LAYER

� Provides generic technical capabilities that

support the higher layers.

� Message sending

� Persistence� Persistence

� Rendering UI widgets

� Etc.

� This layer could be a library or a framework.

CORE OBJECTS

� Entities

� Value Objects

� Services

ENTITIES

“Objects which are not defined by their attributes,

but rather by a thread of

continuity and identity, which remains

the same throughout the life of thethe same throughout the life of the

software and even beyond.”

VALUE OBJECTS

“Immutable objects that have no

conceptual identity and whose only

purpose is to describe some attributepurpose is to describe some attribute

of another object.”

SERVICES

“Objects that have no state and whose

only purpose is to represent an operation

on the domain itself.”on the domain itself.”

PROBLEM

� The domain model is too big to understand.

� Solution: Module.

MODULE

“A method of organizing related concepts

and tasks in order to reduce complexity.”

DOMAIN OBJECT LIFE CYCLE

PROBLEM

� The object graph is biconnected.

� Every object has at least two references to other

objects.

� Hard to enforce invariants.

� Hard to implement database transactions � Hard to implement database transactions

without touching every object in the system.

� Solution: Aggregate.

AGGREGATE

“A cluster of associated objects that are treated as a

unit with regard to data changes.”

All external access to the cluster

is through a single root Entity.is through a single root Entity.

The root Entity enforces invariants

among the other objects.

PROBLEM

� Is the root Entity responsible for creating the

Aggregate?

� Observation: Creation code is different than run-

time behavior code.time behavior code.

� Solution: Factory.

FACTORY

“Encapsulates the knowledge necessary

for complex object creation.”

Relevant patterns:� Relevant patterns:

� Factory Method

� Abstract Factory

� Builder

PROBLEM

� How do you find an Aggregate?

� Navigate a network of object references.

� Increases coupling.

� Pollutes the domain objects with extra references.

� Pull data from the database.Pull data from the database.

� Should SQL go inside the domain objects?

� May violate data hiding principles.

� Solution: Repository.

REPOSITORY

“Encapsulates database storage,

retrieval, and search behavior which

emulates a collection of objects.”

� Looks like java.util.Collection.

� Acts like a relational database.

THE END