1 / 23

Domain-driven design from theory to practice

Domain-driven design from theory to practice. Artur Trosin. Before start. Why DDD nowadays?. Automation of various business domains High competition for a market place Growing business complexity . Why DDD?. Accidental complexity is bad DDD is OO done right Semantics over technology

jerzy
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

  2. Before start

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

  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 • 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.

  9. Atom Model

  10. Even Music has a Model

  11. The key to controlling complexity is a good domain model.

  12. 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”

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

  14. Domain Model - is a rigorously organized and selective abstraction of the Business Domain knowledge.

  15. 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.

  16. 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

  17. 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

  18. Building blocks

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

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

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

  22. DDD : navigation map Repository Services Access with Access with Entities Maintain integrity 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

More Related