What is Clean Architecture ?
Clean Architecture which is also known as Domain-Driven Design has evolved with considerable improvements in the last several years. Some architecture names used for clean architecture over the years are given below:
Hexagonal Architecture (https://en.wikipedia.org/wiki/Hexagonal_architecture_(software))
Onion Architecture
Domain-Driven Design (DDD) or Domain Centric Architecture
vertical Slice Architecture
Clean Architecture
Smell of a good architecture
An architecture design is good when
+ it breaks down the complexity of the software in to manageble and simple problems
+ small interfaced were defined
+ the components are decoupled
+ the components have clearly defined repsponsibilities
+ the software is maintainable
+ the software can be easily changed and extended
+ the software is stable
+ Bugs can fixed quickly
+ the software is reusable in other software projects
+ the code is understandable in a natural way
Smell of a bad architecture
Obviously, a bad architecture have those listed attributed, but in opposite.
Besides, more symptoms are:
+ Small change in requirements leads to big changes in code
+ Developers are afraid to change code
+ Many workarounds, code is developed around it
+ Changes have unknown and undetected side effects
+ Reuse through code duplication (copy-paste). Develops chase after the places that need to be changed
+ Cyclic relations between artifacts. Artifacts that are used in different cycles often play several roles, which makes them difficult to understand, and can not be exchanged easily
Basic Principles behind Clean Architecture
The primary idea in Clean Architecture is to make the solution adaptive, keep the core business or application logic use cases independent of frontend and external frameworks. In summary, we can outline the following outcomes of clean architecture,
Independent of UI
Using clean architecture, we should be able to change UI or presentation layers easily without changing the application layer and so on. UI can be from any front-end framework, or console UI, any web, and can be replaced without changing the other layers or rest of the system.
Database Independent
The architecture should be flexible enough to swap the database without affecting the application use cases and entities. The solution can switch the dataset to MS SQL, MySQL, Oracle, MongoDB, or something else.
Independent of External agency/libraries/Drivers
The business rules should be independent of external parties or agencies.
Framework Independent
The core business or application rules should be independent of the existence of frameworks, libraries for the future. We can include the frameworks but as tools, and the solution should not be completely relied on those.
Testable
The architecture should comply with the testing of the core application and business cases and rules without the UI, database, Web server, or any external component.
Architectural Diagram
Layers of Clean Architecture
Entities
This is also known as enterprise business rules. It consists of plain domains. In this layer, we add objects (entity or domain) with no frameworks and annotations. We add general logics that are applied to every domain like validations, base entities, and so on. They are the least affected by external changes and no dependencies.
Use cases
This is a pure logic layer where we write core business or application logic. This is also called Application Business rules. We, in general, use the term service or manager for application use cases. This layer uses a domain layer and builds results. In this use case, we don’t know who triggers or how the result will be presented. However, based on services, we keep business logic independent of UI or database. We may use some libraries, however, only as tools.
Interface Adapters
This layer acts as a communicator to convert data into desired format for storing into external sources like database, file system, 3rd parties, and convert data for use cases or business logic. This layer is also called as adapters that necessarily do the conversion of data in both ways. We can consider MVC of GUI or REST APIs at this level that consists of presenters, views, and controllers. It also implements the interfaces of use cases required for external components.
External Interfaces, (Frameworks and Drivers)
This is the outermost layer in this clean architecture which changes frequently based on the technologies, updates like database, Web Front-end frameworks. In this layer, we present the data to the UI or database.
Designing and structuring a clean architecture Solution
Domain Class Library – No dependencies, no project or class reference, no logic
Application Class Library – Only Domain is added as reference project, Pure business logic or services.
Domain and Application are the core of this solution which are independent of Infrastructure, WebUI, and external libraries.
Infrastructure Class Library – Application Class is added as reference. This class is responsible for external infrastructure communications like database storage, file system, external systems/APIs/Services and so on.
We can add more class libraries under this folder for external plugins or SDK to organize the solution in a better way.
Web UI – This is a presentation web UI project. This can be an MVC, front-end framework. If we are designing an API based solution, then we can keep both Web API and Front-end in this folder host. We add Application and Infrastructure as reference in this project.
This is a way of organizing and designing a clean architecture solution. This is one way of structuring the solution following the clean architecture principles. However, we can do the organization in several ways, keeping the core values intact.
In this illustration above, we have kept core applications independent and other infrastructure and web UI are dependent on core applications.
In the next article, I will design a real solution demonstrating the clean architecture implementation in .NET 6, stay tuned.
Tool for testing the architecture and Design
Tools to help quickly identify and remediate architecture issues
IntelliJ
Eclipse : install various plugins to visualize dependencies and to detect cycles: eDepend, STAN, jDepend, Java Dependency Viewer
ArchUnit
JQAssistant
Structure 101
Sonargraph
Lattix
Teamscale
Some more keyword about Clean Architecture
Clean Architecture
Basic Principles behind Clean Architecture
Architectural Diagram
Layers of Clean Architecture
Designing and structuring a clean architecture Solution
### Ref
https://rijsat.com/2022/02/01/what-is-clean-architecture/
https://www.c-sharpcorner.com/article/what-is-clean-architecture/
Bài viết khác
Build for global scale: AFK scale cube and basic rule to build an application for global scale
REF https://akfpartners.com/growth-blog/scale-cube
Clean code in writing Go program
When writing code in Go, it is important to follow good coding practices to ensure that your code is clean, maintainable, and scalable. Here are some clean code and clean architecture practices to follow: Go coding style: Follow the official Go coding style guide, which includes recommendations for naming conventions, formatting, and documentation. Consistent coding […]
Interfaces in Go and best practice
Interfaces in Go are a set of methods that defines a behavior. A type can implement an interface by defining methods with the same signatures as the methods defined in the interface. This allows for a form of polymorphism in Go, where a single function or method can operate on values of different types, as […]
Basic concepts of Protocol-Oriented Programming (POP) in swift and ios developer
Protocol-Oriented Programming (POP) is a programming paradigm introduced in Swift that emphasizes the use of protocols as a way to define and enforce common behavior for multiple types. POP is a powerful tool for designing and organizing code, and can be used to achieve many of the same goals as object-oriented programming, but with greater […]
Functional Reactive Programming (FRP) and Imperative Programming :which one to use?
the big idea about Functional Reactive Programming (FRP) and Imperative Programming : which one to use? The choice between using Functional Reactive Programming (FRP) and Imperative Programming often depends on the particular problem being solved and the specific requirements of the project. Here are some general guidelines for when to use FRP and when to […]
Functional Reactive Programming (FRP) for ios developer
Functional Reactive Programming (FRP) is a programming paradigm that has gained popularity among iOS developers due to its ability to handle asynchronous events and its emphasis on immutability, composability, and purity. FRP allows iOS developers to write clean, maintainable code that is easy to understand and to scale. In traditional iOS development, handling asynchronous events […]
Khoá học lập trình game con rắn cho trẻ em 
