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.

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

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

35. WalkthroughanUseCase
Controller
@ivanpaulovich

36. WalkthroughanUseCase
Use Case
@ivanpaulovich

37. WalkthroughanUseCase Repository
@ivanpaulovich

38. WalkthroughanUseCase
Use Case
@ivanpaulovich

39. WalkthroughanUseCase Domain Service
@ivanpaulovich

40. WalkthroughanUseCase Repository
@ivanpaulovich

41. WalkthroughanUseCase Domain Service
@ivanpaulovich

42. WalkthroughanUseCase
Use Case
@ivanpaulovich

43. WalkthroughanUseCase
Use Case
@ivanpaulovich

44. WalkthroughanUseCase
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 metwo questions!
@ivanpaulovich
Fork me on GitHub