Domain Driven Design Javaday Roma2007

25
© ThoughtWorks, 2007 Javaday Roma 2007 Domain Driven Design Antonio Terreno Javaday 1 December 2007, Rome

description

Presentation on DDD Domain Driven Design, Javaday Roma 2007

Transcript of Domain Driven Design Javaday Roma2007

Page 1: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007Javaday Roma 2007

Domain Driven Design

Antonio Terreno

Javaday

1 December 2007, Rome

Page 2: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Software design is art

“Software design is an art, and like any art it cannot be taught and learned as a precise science, by means of theorems and formulas.”

Floyd Marinescu

Page 3: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

The Agile Way

• No upfront design, requirement gathering

• The team makes the design

• Participation with the stakeholder

• Simple, what is simple for you?

• What is good for you?

• Refactoring, refactoring how? (dev skills)

• Refactoring how much? (fear)

Page 4: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Domain Driven Development

• Focus on the domain

• A common language

• Layered architecture

• Entities / Value Objects

• Services

• Modules

• Aggregates

• Factories

• Repositories

Page 5: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Domain Driven

• Layered architecture

– User interface

– Application Layer

• No business logic

• No State of business objects

• Holds state of an application task progress

– Domain Layer

• Info about the domain

• State is held here

– Infrastructure Layer

• Communication between layers

• Persistence for business objects

• Support libraries

Page 6: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Why layers?

• Manage changes

• Avoids coupling of code

• Avoids unexpected behaviors after changes

Page 7: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Entities

• Objects that have an identity

• Spanning the life of the system and even after

• a Person object for example

• The Id does never change

• Some domain objects have already the concept of id

– National number, airport code, …

• All the domain objects are then entities?

Page 8: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

User

public class User {

private string name;

private bool isAuthorised;

private readonly IList myPermissions = new List<Permission>();

protected Guid id;

public User(string name, bool isAuthorised, params Permission[] permissions)

{

id = Guid.Empty;

this.name = name;

this.isAuthorised = isAuthorised;

SetPermissions(permissions);

}

Page 9: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Value Objects

• When we care about what an object has and not about which object is

– How and when write a VO?

• First we write a VO when the object is NOT an Entity!

• Will be great if a VO is immutable

• For performance but mostly

• They will manifest integrity

• If value objects are sharable they should be immutable

• Keep VO thin and simple

• Please no huge VO, a VO can contain value objects and reference to Entities

Page 10: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

TaskRecord

public class TaskRecord

{

private readonly Reference reference;

private readonly decimal value;

private readonly string xml;

private readonly User generatedBy;

private readonly DateTime generationTime;

public TaskRecord(…)

{

this… = …

}

Page 11: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Services

• In the ubiquitous language the objects are the nouns, the services are the verbs.

• A service provides functionality for the domain

• I can’t really put this stuff on an object!

• A service performs an operation

– The operation refers to a domain concept

– The operations refers to other object in the domain model

– The operation is stateless

• Keeps the domain isolated

Page 12: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

IImageReplicationService

public interface IImageReplicationService

{

void Send(ISessionContext sessionContext, Image image, PhotoDetails photoDetails);

}

Page 13: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Tasks & Commands

• Not Stateless operations

• Fairly Isolated

• A Presenter uses one or more Tasks

• A Task can use one more Commands

Page 14: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

SaveUserCommand

public void Execute()

{

user.Username = username;

user.IsAuthorised = isAuthorised;

user.CardNumber = cardNumber;

sessionContext.SaveOrUpdate(user);

}

Page 15: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Modules

• In a complex system the model grows

– Let’s split it in to modules, in order to reduce complexity

– High level of cohesion, low level of coupling

– Communicational cohesion

• Parts of the module work with same data

– Functional cohesion

• Parts of the module work together to perform well-defined tasks

Page 16: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Aggregates

• Relations between objects

– One to many, many to many, complexity!

– First, try to remove and refactor when you don’t need it

– Try to reduce multiplicity and direction (bi to mono)

– Cascade on update/delete, usually the db does this for us

– Typically then what happen? Poor performances!

– Use aggregate

• An aggregate has an entity as root element

• Only the root is obtainable through queries

• The Entity is responsible of maintaining the invariants

Page 17: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Factories

• When creating an objects instance is complex

• When creating an object (especially an Aggregate) is a responsibility

– Use factories.

– I create the root of the Aggregate and all the contained object

– Atomic creation

– Factories violates objects encapsulation, be careful!

– Use a constructor when:

• It’s simple

• All the attributes can be passed via the constructor

• The class is the type, there’s no need to choose different implementation

Page 18: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

IPresenterFactory

public interface IPresenterFactory

{

IPresenter CreateTaskDetailPresenter(ITaskDetailView view, IAddCommentsUserAction addCommentsAction);

}

Page 19: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Repositories

• We don’t want to be coupled to the DB/persistence infrastructure

– A repository encapsulate the logic in order to obtain object references

– It may include a Strategy

– It should be simple (find, add for example)

• A factory creates, a repository retrieves.

• A factory is pure domain, a repository communicates with the infrastructure

Page 20: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

IUserRepository

public interface IUserRepository : IRepository<User>

{

User FindWithCardId(string cardNumber);

ICollection<User> FindAllUsers();

ICollection<User> FindAllActiveUsers();

bool IsUniqueUsername(string username, User currentUser);

bool IsValidUsername(string username);

IList<User> GetUsersByCardId(string cardNumber);

}

Page 21: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

All together

.

Page 22: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Domain Specific Languages

• Small, Domain focused language

• Domain experts themselves can understand, validate, modify, and often even develop DSL programs

• Do I really need a new language?

• Fluent interfaces

Page 23: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

UserBuilder

public class UserBuilder

{

private string name = "UserBuilder generated user";

private bool isAuthorised = true;

private readonly List<Permission> permissions = new List<Permission>();

public UserBuilder Name(string value)

{

name = value;

return this;

}

public UserBuilder CardNumber(string value)

{

cardNumber = value;

return this;

}

public User ToUser()

{

return new User(name, cardNumber, isAuthorised, permissions.ToArray());

}

User testUser = new UserBuilder().Name(“antonio”).CardNumber(“1234”). ToUser();

Page 24: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Dev/BA

• Dev pair sessions with BA

• Domain Experts

• Code that “even” a BA can read and change

Page 25: Domain Driven Design Javaday Roma2007

© ThoughtWorks, 2007

Javaday Roma 2007

Javaday Roma 2007

Q&A?

Grazie!