> For the complete documentation index, see [llms.txt](https://yoan-thirion.gitbook.io/knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yoan-thirion.gitbook.io/knowledge-base/software-craftsmanship/code-katas/clean-architecture.md).
# Clean Architecture
## Connection
* Split the group in 4 :
* Ask this question
* What characteristics do these architectures have in common? - 5'
* Craft as many post-its as they can
* Review what has been produced
#### Hexagonal architecture
#### Onion architecture
## Concepts
### Hexagonal Architecture
{% hint style="info" %}
*Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.*
{% endhint %}
Source :
### Onion Architecture
#### Layers
* ***Domain Model layer***, where our entities and classes closely related to them e.g. value objects reside
* ***Domain Services layer***, where domain-defined processes reside
* ***Application Services layer***, where application-specific logic i.e. our use cases reside
* ***Outer layer***, which keeps peripheral concerns like UI, databases or tests
#### Dependency Inversion Principle (at Architecture Level)
This means that when writing our high-level business logic, we don’t want to depend directly on low-level stuff like databases, file systems, network connections, provider contracts, and such.
{% hint style="success" %}
*Instead, we should expose an abstraction that represents a higher-level business need and implements it using these low-level mechanisms.*
{% endhint %}
### What characteristics do these architectures have in common?
Here is some answers to the connection question :
* Independent of frameworks
* Does not depend on the existence of libraries
* Allow us to use frameworks as tools (not a constraint)
* Independent of the front-end
* Can easily change the UI (from web to console)
* Independent of the database
* Business rules not bound to Database logic
* Independent of any external agency
* Business rules don’t know anything about outside world
{% hint style="success" %}
***Business rules can be tested without external components***
{% endhint %}
### Use Case Driven Approach
Ivar Jacobson in his book below explained we should map 1 Business Use case / 1 Application Use case. We should implement Application Use Case with the BCE "pattern" : Boundary Controller Entity :
### Clean Architecture
The Clean Architecture as expressed by Robert C. Martin is a mix of the 3 architecture ideas explained before :
#### Entities (Enterprise business rules)
* Encapsulate Enterprise wide business rules
* Can be
* Object with methods
* Set of data structures and functions
* Could be used by many different applications in the enterprise.
#### Use cases (Application business rules)
* Capture business rules
* Structure should indicate what the application is, not how it does it
* Application specific business rules
#### Interface adapters
* Set of adapters
* Convert data from the format most convenient for the use cases and entities
* To the format most convenient for some external agency such as the Database or the Web
* In a MVC architecture : Presenters, Views, and Controllers
#### Frameworks & drivers
* Frameworks and tools such as
* Database
* Web Framework
{% hint style="info" %}
*Glue code that communicates to the next circle inwards.*
{% endhint %}
* This layer is where all the details go
* Keep these things on the outside where they can do little harm
#### The dependency rule
{% hint style="success" %}
Source code dependencies can only point inwards.
{% endhint %}
## Concrete Practice
* Clone the repository at :
* Checkout the branch “kata-initial”
### Objective
Learn and practice the concepts behind Clean Architecture
### Part 1
Each participant :
* Position projects on the Clean Architecture Diagram
* Draw the sequence diagram of the Register Use Case
* They can use :
* [https://sequencediagram.org/
]()
*
*
#### Correction
### Part 2
Cover the following use cases and requirements:
* The customer can register a new account.
* Allow to get the customer details.
* Allow to get the account details.
* Allow to deposit into an existing account.
* Allow to withdraw from an existing account.
* Accounts can be closed only if they have zero balance.
* Accounts does not allow to withdraw more than the current account balance.
You can check in the branch **final-solution** to see one possible implementation of those Use Cases
## Conclusion
* What benefits do you see?
* Pros and cons ?
### Pros & Cons
| Pros | Cons |
| ------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- |
| ***Plays well with DDD*** – architecture that builds everything on top of a domain model | ***Learning curve*** – People tend to mess up splitting responsibilities between layers, especially harming the domain model |
| ***Directed coupling*** – the most important code in our application depends on nothing, everything depends on it | ***Indirection*** – interfaces everywhere! |
| ***Flexibility*** – from an inner-layer perspective, you can swap out anything in any of the outer layers and things should work just fine | ***Potentially heavy*** |
| ***Testability*** – since your application core does not depend on anything else, it can be easily and quickly tested in isolation | |
## Support
{% embed url="" %}
## Resources
* Hexagonal Architecture :
* Onion Architecture : [https://bitbucket.org/jeffreypalermo/onion-architecture/src]()
* Clean Architecture :
* A simple template for Onion Architecture with .NET 5 :
