Tactical Design & Clean Architecture

https://www.youtube.com/watch?v=hf_XBb5cSoA

Transcript

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) Entities Entities Entities 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 @ivanpaulovich 22 Ports and Adapters Cloud Messaging UI In Memory Persistence Tests In Memory Messaging SQL Secondary Actors
23. Entities Entities Clean Architecture 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 UI DB Web External Interfaces Abstract,
 General,
 Stable,
 Consistent Concrete,
 Specific, 
 Unstable, Inconsistent Level Clean Architecture @ivanpaulovich
25. Use Case @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 Security Exchange @ivanpaulovich
32. Application Unit Test Web Database Domain Primary Actors Secondary Actors @ivanpaulovich 32 Infrastructure Ports and Adapters
33. Infra Services Controller Use Case Domain Service Domain Service Unit of Work Repository Repository Core Infrastructure GUI @ivanpaulovich
34. @ivanpaulovich Splitting packages on the software lifetime Domain Application Infrastructure User Interface Tests Tests Core Tests Core Infrastructure 2nd 1st 3rd 4th
35. Walkthrough an Use Case Controller @ivanpaulovich
36. Walkthrough an Use Case Use Case @ivanpaulovich
37. Walkthrough an Use Case Repository @ivanpaulovich
38. Walkthrough an Use Case Use Case @ivanpaulovich
39. Walkthrough an Use Case Domain Service @ivanpaulovich
40. Walkthrough an Use Case Repository @ivanpaulovich
41. Walkthrough an Use Case Domain Service @ivanpaulovich
42. Walkthrough an Use Case Use Case @ivanpaulovich
43. Walkthrough an Use Case Use Case @ivanpaulovich
44. Walkthrough an Use Case Controller @ivanpaulovich
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 me two questions! @ivanpaulovich Fork me on GitHub