• Save
2011   iska - tim m - domain driven design
Upcoming SlideShare
Loading in...5

2011 iska - tim m - domain driven design



Public session given about DDD

Public session given about DDD



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

2011   iska - tim m - domain driven design 2011 iska - tim m - domain driven design Presentation Transcript

  • Domain Driven Design Tim Mahytimm@infosupport.com
  • 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
  • Warning
  • Why ? The critical complexity of most software projects is in understanding the business domain itself.
  • 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
  • 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
  • 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 domain of the software.
  • The model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
  • 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!
  • 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
  • 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
  • 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
  • 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
  • The essence Seperate – Business logic – Infrastructure
  • The patterns Modules The domain objects – Entities – Value types – Services Aggregates Repositories Factories Specification Anti corruption layer
  • Modules Functional partitions inside a domain model Should be part of the ubiquitous language Example: – Reference Data • Logistics • Procurement • Organisation
  • 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 when exposed on a client so that the client can hold on to them (<> entities)
  • The domain objects Services – Encapsulate business logic – Cross entity logic – Correspond to verbs in the ubiquitous language – Stateless Try to limit
  • 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)
  • 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.
  • 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
  • Repositories Exposes query possibilities in an in-memory style database of root aggregates Interface = model Implementation = infrastructure Responsible for UOW, Change Tracking…
  • Specification Place business rules inside predicate objects Can be used as predicates to factory or repositories Can be used to evaluate conditions
  • Specification
  • SpecificationIf ( customer.NumberOfOrders > 100 && customer.NumberOfDelayedPayment == 0){…..}If( new ThrustedCustomer().IsSatifiedBy( customer )){…..}If( new ThrustedCustomer().Or( new VeryRichCustomer() ).IsSatifiedBy( customer )){…..}
  • Anti-corruption layer Bridges the layer to other worlds Traditional: mapping to bridge communications Bridge between different bounded contexts
  • Do Domain objects can also represent a process Keep refactoring to keep clean codecustomer.Address = new Address( …customer.MoveToNewAddress( new Address …
  • 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
  • DoTry to write BDD tests: – When – Given – Then
  • 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?
  • 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 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());
  • Don’t Do only some of the patterns Start without reading
  • Questions
  • CQRSCommandQueryResponsibilitySeggregation
  • UI DataStore Queries SubscribeUI Commands EventBus Business Logic Publish Truth (optional)