Domain 1: Planning & Preparation Domain 2: Classroom Environment Domain 3: Instruction
Domain Driven Design Javaday Roma2007
-
Upload
antonio-terreno -
Category
Technology
-
view
4.055 -
download
0
description
Transcript of Domain Driven Design Javaday Roma2007
© ThoughtWorks, 2007Javaday Roma 2007
Domain Driven Design
Antonio Terreno
Javaday
1 December 2007, Rome
© 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
© 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)
© 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
© 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
© ThoughtWorks, 2007
Javaday Roma 2007
Javaday Roma 2007
Why layers?
• Manage changes
• Avoids coupling of code
• Avoids unexpected behaviors after changes
© 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?
© 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);
}
© 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
© 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… = …
}
© 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
© ThoughtWorks, 2007
Javaday Roma 2007
Javaday Roma 2007
IImageReplicationService
public interface IImageReplicationService
{
void Send(ISessionContext sessionContext, Image image, PhotoDetails photoDetails);
}
© 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
© ThoughtWorks, 2007
Javaday Roma 2007
Javaday Roma 2007
SaveUserCommand
public void Execute()
{
user.Username = username;
user.IsAuthorised = isAuthorised;
user.CardNumber = cardNumber;
sessionContext.SaveOrUpdate(user);
}
© 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
© 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
© 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
© ThoughtWorks, 2007
Javaday Roma 2007
Javaday Roma 2007
IPresenterFactory
public interface IPresenterFactory
{
IPresenter CreateTaskDetailPresenter(ITaskDetailView view, IAddCommentsUserAction addCommentsAction);
…
}
© 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
© 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);
}
© ThoughtWorks, 2007
Javaday Roma 2007
Javaday Roma 2007
All together
.
© 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
© 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();
© 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
© ThoughtWorks, 2007
Javaday Roma 2007
Javaday Roma 2007
Q&A?
Grazie!