Domain Driven Design Javaday Roma2007

Domain Driven Design Antonio Terreno Javaday 1 December 2007, Rome Javaday Roma 2007 © ThoughtWorks, 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 Javaday Roma 2007 © ThoughtWorks, 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) Javaday Roma 2007 © ThoughtWorks, 2007

Javaday Roma 2007 Domain Driven Development • Focus on the domain • A common language • Layered architecture • Entities / Value Objects • Services • Modules • Aggregates • Factories • Repositories Javaday Roma 2007 © ThoughtWorks, 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 Javaday Roma 2007 © ThoughtWorks, 2007

Javaday Roma 2007 Why layers? • Manage changes • Avoids coupling of code • Avoids unexpected behaviors after changes Javaday Roma 2007 © ThoughtWorks, 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? Javaday Roma 2007 © ThoughtWorks, 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); } Javaday Roma 2007 © ThoughtWorks, 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 Javaday Roma 2007 © ThoughtWorks, 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… = … } Javaday Roma 2007 © ThoughtWorks, 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 Javaday Roma 2007 © ThoughtWorks, 2007

Javaday Roma 2007 IImageReplicationService public interface IImageReplicationService { void Send(ISessionContext sessionContext, Image image, PhotoDetails photoDetails); } Javaday Roma 2007 © ThoughtWorks, 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 Javaday Roma 2007 © ThoughtWorks, 2007

Javaday Roma 2007 SaveUserCommand public void Execute() { user.Username = username; user.IsAuthorised = isAuthorised; user.CardNumber = cardNumber; sessionContext.SaveOrUpdate(user); } Javaday Roma 2007 © ThoughtWorks, 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 Javaday Roma 2007 © ThoughtWorks, 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 Javaday Roma 2007 © ThoughtWorks, 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 Javaday Roma 2007 © ThoughtWorks, 2007

Javaday Roma 2007 IPresenterFactory public interface IPresenterFactory { IPresenter CreateTaskDetailPresenter(ITaskDetailView view, IAddCommentsUserAction addCommentsAction); … } Javaday Roma 2007 © ThoughtWorks, 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 Javaday Roma 2007 © ThoughtWorks, 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); } Javaday Roma 2007 © ThoughtWorks, 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 Javaday Roma 2007 © ThoughtWorks, 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(); Javaday Roma 2007 © ThoughtWorks, 2007

Javaday Roma 2007 Dev/BA • Dev pair sessions with BA • Domain Experts • Code that “even” a BA can read and change Javaday Roma 2007 © ThoughtWorks, 2007

Domain Driven Design Javaday Roma2007

0 comments

Notes on slide 1

6 Favorites