1 / 37

Domain-driven design from theory to practice

Domain-driven design from theory to practice. Artur Trosin. Presentation for: Software as Craft 2009, 14-16 May. Before start. Why DDD nowadays?. Automation of various business domains High competition for a market place Growing business complexity Complexity becomes inevitable .

nile
Télécharger la présentation

Domain-driven design from theory to practice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Domain-driven designfrom theory to practice Artur Trosin Presentation for: Software as Craft 2009, 14-16 May

  2. Before start

  3. Why DDD nowadays? • Automation of various business domains • High competition for a market place • Growing business complexity • Complexity becomes inevitable

  4. Why DDD? • Accidental complexity is bad • DDD is OO done right • Semantics over technology • Is discovered and NOT invented

  5. DDD benefits? • Reduced complexity • High maintainability • Continuous collaboration and feedback • Brings to front the “Core Domain Knowledge” • Translations are reduced to minimum

  6. Domain - particular field of knowledge

  7. Complexity of most software projects is understanding the business domain and not a technical one.

  8. Domain Driven Design is based on models. Atom Model

  9. Even Music has a Model

  10. The key to controlling complexity is a good domain model. Martin Fowler

  11. They are two different worlds! Business Domain (business experts) Software Development (development team) We need to bring them together (business domain & technical) Successes depends on “how well you bring them together”

  12. We need common view and language! Software Development BusinessDomain DomainModel & Ubiquities Language

  13. Domain Model- is a rigorously organized and selective abstraction of the (Business) Domain knowledge.

  14. Ubiquitous Language - A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

  15. Ubiquitous Language Business terms developers don’t understand Technical terms Domain Model Terms Technical aspects of design DDD Patterns Technical design patterns Business terms everyone uses that don’t appear in design Bounded Contexts S.O.L.I.D design principles Candidates to fold into model

  16. Collaboration Domain Experts and Developers produce Model Software Development BusinessDomain Produce DomainModel & Ubiquities Language Software Reflected in Based on Direct mapping between business domain concepts and software artifacts

  17. Building blocks

  18. Classic Layering UI Record Sets or Data Sets or POCO or POJO Business Entities Data Access DB

  19. DDD recommended-Layering Service Layer UI UI Application Domain Model Domain Infrastructure Infrastructure Service Getaways

  20. Organizing Domain Logic Patterns Transaction Script Table Module Effort to enhance Domain Model Complexity of Domain Logic Source : PoEAA by Martin Fowler

  21. A model expressed in software with: Life Cycle of domain object controlled by: Repository Services Modules Access with Access with Entities Maintain integrity with Express model with Express model with Express model with Act as root of Aggregates Model-Driven Design Express model with Value Objects Encapsulate with X Isolate domain with Encapsulate with Encapsulate with Mutually exclusive choice Layered Architecture Encapsulate with Factories Smart UI

  22. Associations Country Country Country Period President President President * * * Person Person Person

  23. Entities • An object defined primarily by its identity and not its attributes • Could be a person, a customer, an order, etc. • Not all objects have meaningful identities… • In some systems, a class may be an ENTITY, in others maybe not

  24. Value Objects • Represent an aspect of the domain with NO conceptual identity • Use when you care about what something is, not who they are • Simple, immutable objects • NOT is same thing as a DTO [Fowler PoEAA]

  25. Services • An operation offered as an interface that stands alone in the model • Does not fit into any of the objects in the model • Stateless • To be used judiciously (do not turn your app into a Transaction Script) • Use when an operation is an important domain concept

  26. Modules • Is larger grain of modeling and design • A method of organized related concepts • Low coupling and high cohesion • Communications mechanism. • Could be Administration, Invoicing, Reports,…

  27. Aggregates • A cluster of associated objects that is treated as a conceptual whole • Define consistency boundaries • A unit for the purpose of data changes • Is controlled by root

  28. Factories • Shifts complicated object creation to FACTORY • Enforce invariants • Decouple clients and hide creation details

  29. Repositories • Provide illusion of an in-memory collection • Provide a simple model for obtaining persistent objects • Decouple domain model from persistence technology • Communicate design decisions about object access • IS NOT just DAO with CRUD

  30. Cargo Sample

  31. Collecting Basic requirements • Book cargo in advance • Track key handling of customer cargo

  32. Itinerary

More Related