# 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/
](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 :
* Clean Architecture :
* A simple template for Onion Architecture with .NET 5 :
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://yoan-thirion.gitbook.io/knowledge-base/software-craftsmanship/code-katas/clean-architecture.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.