DDD Tactical Design with Clean Architecture - Ivan Paulovich
3 likes•3,244 views
The document discusses tactical design and clean architecture. It begins with an introduction of the speaker and then defines tactical design as applying design patterns and building blocks within a bounded context to enrich the domain model in a hands-on way. It then defines clean architecture as having patterns, principles, and practices with classes and modules that follow principles of dependency inversion, stable abstractions, and stable dependencies. The rest of the document provides examples of tactical design and clean architecture concepts like entities, value objects, aggregates, and domain-driven design patterns.
DDD Tactical Design with Clean Architecture - Ivan Paulovich
- 1. Tactical Design and Clean Architecture Ivan Paulovich Stockholm Domain-Driven Design Meetup January 30, 2020 https://paulovich.net@ivanpaulovich
- 2. Ivan Paulovich Agile Software Developer, Tech Lead, 20+ GitHub projects about Clean Architecture, SOLID, DDD and TDD. Speaker/Streamer. @ivanpaulovich
- 3. Tactical Design • Design Patterns and Building Blocks applied within a Bounded Context. • Used to enrich the Domain Model. • It is hands-on (Classes, Modules)! • It is the opposite of Anaemic Model! @ivanpaulovich
- 4. Clean Architecture • Patterns (not too many). • Principles (lots of them). • Practices (TDD?). • Hands-on (Classes, Modules) EntitiesEntitiesEntities Use Cases Controllers Gatew ays Presenters D evices W eb UI DB External Interfaces @ivanpaulovich
- 5. • Building Blocks • Aggregate • Entity • Value Object • Domain Service • Ports and Adapters • Dependency Inversion Principle • Stable Abstractions Principle. • Stable Dependencies Principle. • SOLID • TDD • Use Cases Tactical Design Clean Architecture @ivanpaulovich
- 6. Domain-Driven Design Patterns • Bounded Context • Value Object • Entity • Aggregate Root • Repository • Use Case • Entity Factory • Domain Service • Application Service @ivanpaulovich
- 7. Virtual Wallet Customer Checking Account Credit Debit Openning Date Amount Transaction Date Description Amount Transaction Date Description Name Personnummer Mobile Phone Number Aggregate Root Entity Value Object @ivanpaulovich
- 8. Entity 1. Highly abstract. 2. Mutable object. 3. Unique identified by an ID (inside the aggregate). @ivanpaulovich
- 9. Value Object 1. Encapsulate tiny business rules. 2. Immutable object. 3. Unique identified by comparison of the properties. @ivanpaulovich
- 10. Aggregate Root 1. Owns entities object graph. 2. Ensures the children entities state are always consistent. 3. Defines the consistency boundary. 4. Highly Abstract. 5. Highly Stable. @ivanpaulovich
- 11. Aggregate Root 1. Owns entities object graph. 2. Ensures the children entities state are always consistent. 3. Defines the consistency boundary. 4. Highly Abstract. 5. Highly Stable. @ivanpaulovich
- 12. Aggregates Together Aggregate Entity Value Object Value Object Entity Value Object Aggregate • Aggregates know each other only by ID. • Keep a low coupling between them. @ivanpaulovich
- 13. Repository 1. Provides persistence capabilities to Aggregate Roots. 2. A Repository for every Entity is a code smell. @ivanpaulovich
- 14. Domain Service • Cross-entities functions. • Without side effects outside the application memory. @ivanpaulovich
- 15. Architecture The Lost Years by Robert C. Martin @ivanpaulovich
- 16. Architecture UML - Uncle Bob @ivanpaulovich
- 17. The “Software Architecture” Presentation Layer ASP.NET MVC and Autofac Business Layer MediatR and AutoMapper Data Layer Entity Framework and Dapper Database and Messaging SQL Server and RabbitMQ IDE and Tools Visual Studio, Resharper and .NET Framework 17 @ivanpaulovich
- 18. The “Software Architecture” Presentation Layer ASP.NET MVC and Autofac Business Layer MediatR and AutoMapper Data Layer Entity Framework and Dapper Database and Messaging SQL Server and RabbitMQ IDE and Tools Visual Studio, Resharper and .NET Framework 18 @ivanpaulovich Not a Software Architecture!
- 19. Architecture is About Usage 19 @ivanpaulovich
- 20. Clean Architecture • Use Cases as central organising structure. • Follows the Ports and Adapters pattern (Hexagonal Architecture). • The implementation is guided by tests. • It is decoupled from technology details. • Follows lots of Principles (Stability, Abstractness, Dependencies, SOLID). • Pluggable User Interface. @ivanpaulovich
- 21. Ticket Terminal Ticket Terminal Display movies Request movie details Print pre-ordered tickets Order tickets Customer Movie Catalog Order System Credit Processing Use Cases • Use Cases are delivery independent. • Show the intent of a system. • Use Cases are algorithms that interpret the input to generate the output data. • Primary and secondary actors. 21 @ivanpaulovich
- 22. Business v Primary Actors @ivanpaulovich22 Ports and Adapters CloudMessaging UI In Memory Persistence Tests In MemoryMessaging SQL Secondary Actors
- 23. EntitiesEntities CleanArchitecture Entities Use Cases Controllers Gatew ays Presenters D evices W eb UI DB External Interfaces @ivanpaulovich •Abstractness increases with stability. •Modules depend in the direction of stability. •Classes that change together are packaged together.
- 24. Entities Use Cases Controllers Presenters Gateways Devices UIDB Web External Interfaces Abstract, General, Stable, Consistent Concrete, Specific, Unstable, Inconsistent Level CleanArchitecture @ivanpaulovich
- 26. Use Case Input and Output Messages 1. Immutable. 2. Consistent-ish @ivanpaulovich
- 27. Architecture UML - Uncle Bob @ivanpaulovich
- 28. Microservices? Are you moving from Monolith into Microservices? Try moving from Monolith into Modular-Monolith instead. @ivanpaulovich
- 29. Microservices? • Low coupling between aggregates. • Adapters for dependencies. • Defer extracting an Aggregate. @ivanpaulovich
- 30. Bounded Context • Another way of saying a Module, Logical Organisation or Component. • Developed and tested independently. • Deployment separately is an option/decision. @ivanpaulovich
- 31. • Context Map sets the relationship between contexts. • Conformist. • Shared Kernel. • Customer / Supplier. • Anti-Corruption Layer. Bounded Context Customers Accounts SecurityExchange @ivanpaulovich
- 32. Application Unit Test Web Database Domain Primary Actors Secondary Actors @ivanpaulovich32 Infrastructure Ports and Adapters
- 33. Infra Services Controller Use Case Domain Service Domain Service Unit of Work Repository Repository Core InfrastructureGUI @ivanpaulovich
- 34. @ivanpaulovich Splitting packages on the software lifetime Domain Application Infrastructure User Interface Tests Tests Core Tests Core Infrastructure 2nd1st 3rd 4th
- 45. Wrapping up Tactical Design • It enriches the Domain Model. • It applies Encapsulation, hides details. • Focus on usage. • Unambiguity. • High consistency inside the domain. 45 @ivanpaulovich
- 46. Wrapping up Clean Architecture • Clean Architecture is about usage and the use cases are the central organizing principle. • Use cases implementation are guided by tests. • The User Interface and Persistence are designed to fulfil the core needs (not the opposite!). • Defer decisions by implementing the simplest component first. 46 @ivanpaulovich
- 47. References https://cleancoders.com Clean Code: Component Design Clean Code: SOLID Principles Clean Code: Fundamentals https://github.com/ivanpaulovich/clean-architecture-manga Robert C Martin - Clean Architecture and Design @ivanpaulovich
- 48. 48 Ask metwo questions! @ivanpaulovich Fork me on GitHub