O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Refreshing Domain Driven Design


Confira estes a seguir

1 de 41 Anúncio

Mais Conteúdo rRelacionado

Semelhante a Refreshing Domain Driven Design (20)

Mais recentes (20)


Refreshing Domain Driven Design

  1. 1. Andre Borgonovo
  2. 2. An approach to the development of complex software In which we: 1. Focus on the core domain 2. Explore models in a creative collaboration of domain practitioners and software practitioners 3. Speak a ubiquitous language within an explicitly bounded context
  3. 3. OK, BUT WHY? IS IT FOR ME?
  4. 4. DOMAIN “A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.”
  5. 5. “Essentially, all models are wrong, but some are useful.”1  System of abstractions  Describe selected aspects of the domain  Solve problems 1: George E. P. Box, British
  6. 6. “A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software.”
  7. 7. https://martinfowler.com/bliki/BoundedContext.html
  9. 9. Isolating the domain
  10. 10. Responsible for showing information to the user and interpreting the user’s commands. External actor can be - A human user or; - Another computer system.
  11. 11.  Application Services (and/or Command Handlers)  Adapters  Workflows
  12. 12. The heart of the business software  Entities  Aggregates  Value Objects  Repository interfaces  Factories  Domain Events  Domain Services
  13. 13.  Data Persistence (Repositories implementation)  Gateways to external dependencies  Infrastructure Services  Crosscutting concerns:  Logging  Exception Handling  Security  Caching  ...
  14. 14. User Interface Application Domain Infrastructure Infrastructure Persistencedepends on compose
  15. 15. MODEL ELEMENTS Expressing the Model in Software
  16. 16. “An object primarily defined by its identity”  Artificial x Natural identity  Anemic Domain (aka Reference Objects) https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/microservice-domain-model
  17. 17.  No identity  Immutable
  18. 18.  Root Entity (also called Aggregate Root)  State changes are made via the root Entity, which ensure the Business rules and keeps the Aggregate valid  All children have a reference to the root Entity  Deletion of the aggregate/root, deletes all children;
  19. 19. https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/microservice-domain-model
  20. 20. https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/microservice-domain-model
  21. 21. 3 types of services  Application Services  Domain Services  Infrastructure Services Characteristics of a good Domain Service  Operation relates to a domain concept that is not a natural part of na Entity or Value Object  The interface is defined in terms of other elements of the domain model  The operation is stateless
  22. 22. FACTORIES When creation of an entire, internally consistente aggregate, or a large value object, becomes complicated or reveals too much of the internal structure, factories provide encapsulation.
  23. 23. Query access to aggregates expressed in the ubiquitous language.  Act in a similar way to a set of domain objects in memory  Persistence Ignorance Principle  One repository per aggregate  No business rules
  24. 24.  A representation of something that happened in the domain  Immutable  Domain Event != System Event
  25. 25. @DDD_Borat
  26. 26. COMMON PITFALLS  Relational database mindset masked as DDD  Treating DDD as a recipe  Starting with technical details  Being superficial about the Domain  The "One model to rule them all" approach  …
  28. 28. Intention- Revealing Interfaces Side-Effect- Free Functions Assertions Standalone Classes Closure of Operations Declarative Design Drawing on Established Formalisms Conceptual Contours
  29. 29. Context Map Partnership Shared Kernel Customer/ Supplier Development Conformist Anticorruptio n Layer Open-host Service Published Language Separate Ways Big Ball of Mud
  30. 30. DISTILLATI ON FOR STRATEGIC DESIGN Core Domain Generic Subdomains Domain Vision Statement Highlighted Core Cohesive Mechanisms Segregated Core Abstract Core
  32. 32. https://devblogs.microsoft.com/cesardelatorre/domain-driven-design-ddd-visual-studio-11-beta-alm-great-fit/
  33. 33. MORE  http://domainlanguage.com/  https://docs.microsoft.com/en- us/dotnet/standard/microservices- architecture/microservice-ddd-cqrs-patterns/  https://github.com/VaughnVernon/IDDD_Samples  https://aspnetboilerplate.com/  https://github.com/vlingo
  34. 34. ANDRE BORGONOVO Software Consultant at WAES Design Engineer at ASML MCSD, PSM, ITIL linkedin.com/in/azborgonovo @azborgonovo Software Developer | Leader | Architect

Notas do Editor

  • Increases the project architecture quality
    Decreases complexity
    Improves the manutenability

    You make software to run for years

    Who should care about Domain-driven design?

    DDD is forever (technology independente, not only OOP)

    Comes along with other DDs
  • The focus is on the domain
    NOT on the database
    Business software with complex rules
  • Should be kept up to date
    Use POCO (Plain Old CLR Objects)
  • Ubiquitous = it is everywhere
    The language used by the Business expert = Domain expert = Product Owner
    Do not use tech language to talk with the Domain expert
    Proximity with the Domain expert
    Analysis should be natural to the Domain expert
    Nouns => Classes
    Verbs => Methods, services
  • Continuous Integration => Once a bounded context has been defined, we must keep it sound
  • Layers vs Tiers, Tier is a physical unit where the code/process runs

    Separation of Responsabilities

    Flexible architecture
  • Thin layer, no domain logic, no state (only state for long running processes)

    Command Handlers
    Domain Event Handlers
  • Hexagonal Architecture

    If I have this architecture, do I have DDD?

  • An entity’s identity can cross multiple microservices or Bounded Contexts.
  • Watch out for generic repositories
  • IntegrationEvents
  • Making behavior obvious
    Reducing the cost of changes
    Creating software developers like to work with
  • Making behavior obvious
    Reducing the cost of changes
    Creating software developers like to work with
  • When to use it? For the development of complex software

    Go DDD, go Agile!

    Software becomes higly adaptable

    Close to the Domain Expert