Domain Driven   Design     Tim Mahytimm@infosupport.com
Content Why ?                         Patterns (demo) What ?                        –   Modules Where ?                   ...
Warning
Why ?        The critical complexity of         most software projects         is in understanding the         business do...
What ?Domain Driven design is not a technology or a              methodology.      It’s a way of thinking and a set of  pr...
What ? Guidance upon a proven technique – Patterns to keep domain consistent and clean – Strategies on development respons...
Where ? High business complexity Works well for business services inside a SOA
The fundamentals The domain The model The domain model The ubiquitous language The bounded context
The domain A sphere of knowledge, influence, or activity. The subject area to which the user applies a    program is the d...
The model        A system of abstractions         that describes selected           aspects of a domain        and can be ...
The domain model What needs to be build Distilled knowledge about the domain – For the scope of the project – Consists of ...
The domain model The model and the heart of the design shape each other – They are linked – Understanding the model allows...
The ubiquitous language Common language between IT and business – Avoid miscommunication – Based upon a shared conceptual ...
The bounded context One model to rule them all is a non cost- effective dream Create boundaries based upon the context, th...
Knowledge rich design It’s more than ‘finding nouns’ Not only about entities but also about rules & constraints Implicit c...
The essence Seperate – Business logic – Infrastructure
The patterns Modules The domain objects – Entities – Value types – Services Aggregates Repositories Factories Specificatio...
Modules Functional partitions inside a domain model Should be part of the ubiquitous language Example: – Reference Data   ...
The domain objects Entities Value objects Services
The domain objects Entities – Data & behavior – Not your persistance entities (no DTO) – Functional identity
The domain objects Value objects – Value = combination of all values – Have no identity Try to make – Immutable – Copied w...
The domain objects Services – Encapsulate business logic – Cross entity logic – Correspond to verbs in the ubiquitous lang...
Aggregates Combination of entities & value objects One entity is ‘root’ of the aggregate Ensures consistent state & data i...
Aggregates Client code cannot make changes to parts of the aggregate unless it uses methods on the aggregate root. Entitie...
Factories Build up aggregates (Abstract) Factory pattern Not always needed Mostly with a fluent API interface May break en...
Repositories Exposes query possibilities in an in-memory style database of root aggregates Interface = model Implementatio...
Specification Place business rules inside predicate objects Can be used as predicates to factory or repositories Can be us...
Specification
SpecificationIf ( customer.NumberOfOrders > 100 && customer.NumberOfDelayedPayment == 0){…..}If( new ThrustedCustomer().I...
Anti-corruption layer Bridges the layer to other worlds Traditional: mapping to bridge communications Bridge between diffe...
Do Domain objects can also represent a process Keep refactoring to keep clean codecustomer.Address = new Address( …custom...
DoWork always test first – Enhances your ‘client’ APIUse terms of the ubiquitous for yourclass/interface namesStrive towor...
DoTry to write BDD tests: – When – Given – Then
DoImplement cohesive mechanisms – Generic: Time slicing, Graph traversal, History – Seperate framework – Try to go declara...
Do   Apply SOLID principles very strictnewStatus = 3; // GoldCustomer.Update(newStatus, null);Customer.UpgradeToGoldStatus...
DoClosure of operationsPigment red = new Pigment();Pigment blue = new Pigment();Pigment purple= red.Mix(blue);
DoDeclarative programming is a programming style where thespecification becomes executable – Either by an interpreted lang...
Don’t Do only some of the patterns Start without reading
Questions
CQRSCommandQueryResponsibilitySeggregation
UI DataStore     Queries                                           SubscribeUI   Commands                                 ...
2011   iska - tim m - domain driven design
Upcoming SlideShare
Loading in...5
×

2011 iska - tim m - domain driven design

435

Published on

Public session given about DDD

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
435
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "2011 iska - tim m - domain driven design"

  1. 1. Domain Driven Design Tim Mahytimm@infosupport.com
  2. 2. Content Why ? Patterns (demo) What ? – Modules Where ? – The domain objects – Aggregates Fundamentals – Repositories – The domain – Factories – The model – Specification – The domain model – Anti corruption layer – The ubiquitous language – The bounded context Best practices
  3. 3. Warning
  4. 4. Why ? The critical complexity of most software projects is in understanding the business domain itself.
  5. 5. What ?Domain Driven design is not a technology or a methodology. It’s a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains
  6. 6. What ? Guidance upon a proven technique – Patterns to keep domain consistent and clean – Strategies on development responsibility and integrity – Principles & practices for the development process
  7. 7. Where ? High business complexity Works well for business services inside a SOA
  8. 8. The fundamentals The domain The model The domain model The ubiquitous language The bounded context
  9. 9. The domain A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.
  10. 10. The model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
  11. 11. The domain model What needs to be build Distilled knowledge about the domain – For the scope of the project – Consists of a language that is spoken by the whole team AND the business!
  12. 12. The domain model The model and the heart of the design shape each other – They are linked – Understanding the model allows you to interpret the code
  13. 13. The ubiquitous language Common language between IT and business – Avoid miscommunication – Based upon a shared conceptual model – Close to domain experts & developers – Free of misconceptions or contradictions The language of the team – Accept and learn together – Refine understanding over time – Iron out misconceptions and contradictions – To ensure that all members have the same understanding of the words used over time
  14. 14. The bounded context One model to rule them all is a non cost- effective dream Create boundaries based upon the context, the model will only be valid inside this boundaries Context map to model relationships between multiple models Conceptual splinters indicate different model – Duplicate concepts – False cognates
  15. 15. Knowledge rich design It’s more than ‘finding nouns’ Not only about entities but also about rules & constraints Implicit concepts should be explicit Knowledge in the design is a developers best documentation Supple design ready for refactoring
  16. 16. The essence Seperate – Business logic – Infrastructure
  17. 17. The patterns Modules The domain objects – Entities – Value types – Services Aggregates Repositories Factories Specification Anti corruption layer
  18. 18. Modules Functional partitions inside a domain model Should be part of the ubiquitous language Example: – Reference Data • Logistics • Procurement • Organisation
  19. 19. The domain objects Entities Value objects Services
  20. 20. The domain objects Entities – Data & behavior – Not your persistance entities (no DTO) – Functional identity
  21. 21. The domain objects Value objects – Value = combination of all values – Have no identity Try to make – Immutable – Copied when exposed on a client so that the client can hold on to them (<> entities)
  22. 22. The domain objects Services – Encapsulate business logic – Cross entity logic – Correspond to verbs in the ubiquitous language – Stateless Try to limit
  23. 23. Aggregates Combination of entities & value objects One entity is ‘root’ of the aggregate Ensures consistent state & data integrity Root entity is navigational start for other data (via associations)
  24. 24. Aggregates Client code cannot make changes to parts of the aggregate unless it uses methods on the aggregate root. Entities and value objects in an aggregate can only hold references to other aggregate roots.
  25. 25. Factories Build up aggregates (Abstract) Factory pattern Not always needed Mostly with a fluent API interface May break encapsulation Must ensure atomic creation & invariants Think of identity creation
  26. 26. Repositories Exposes query possibilities in an in-memory style database of root aggregates Interface = model Implementation = infrastructure Responsible for UOW, Change Tracking…
  27. 27. Specification Place business rules inside predicate objects Can be used as predicates to factory or repositories Can be used to evaluate conditions
  28. 28. Specification
  29. 29. SpecificationIf ( customer.NumberOfOrders > 100 && customer.NumberOfDelayedPayment == 0){…..}If( new ThrustedCustomer().IsSatifiedBy( customer )){…..}If( new ThrustedCustomer().Or( new VeryRichCustomer() ).IsSatifiedBy( customer )){…..}
  30. 30. Anti-corruption layer Bridges the layer to other worlds Traditional: mapping to bridge communications Bridge between different bounded contexts
  31. 31. Do Domain objects can also represent a process Keep refactoring to keep clean codecustomer.Address = new Address( …customer.MoveToNewAddress( new Address …
  32. 32. DoWork always test first – Enhances your ‘client’ APIUse terms of the ubiquitous for yourclass/interface namesStrive towords command query responsibilityseggregation to divide operationsUse code contractsSplit functional keys from entitiesMake generic value types
  33. 33. DoTry to write BDD tests: – When – Given – Then
  34. 34. DoImplement cohesive mechanisms – Generic: Time slicing, Graph traversal, History – Seperate framework – Try to go declarativeDon’t be afraid of generic subdomains – Reference data not specific to the problem domainSegregate the core from the less importantpartsAbstract core?
  35. 35. Do Apply SOLID principles very strictnewStatus = 3; // GoldCustomer.Update(newStatus, null);Customer.UpgradeToGoldStatus();
  36. 36. DoClosure of operationsPigment red = new Pigment();Pigment blue = new Pigment();Pigment purple= red.Mix(blue);
  37. 37. DoDeclarative programming is a programming style where thespecification becomes executable – Either by an interpreted language like a DSL or runtime code generation • This technique has a lot of merits • But can impose some risks as well – Many of the benefits of a declarative design can be reached as well by combining • intention-revealing interfaces, side effect-free functions, conceptual contours and closure of operations • A fully implemented specification pattern: var isAllowedToDrive = IsOlderThan(18) & DoesNotDrink(); • Or a fluent interface c = new CustomerBuilder() .AsGoldCustomer() .WithInitialBalanceOf(100.Euros());
  38. 38. Don’t Do only some of the patterns Start without reading
  39. 39. Questions
  40. 40. CQRSCommandQueryResponsibilitySeggregation
  41. 41. UI DataStore Queries SubscribeUI Commands EventBus Business Logic Publish Truth (optional)

×