Clean Architecture (Pure architecture) (Category Architecture)

I read this book by Uncle Bob. (Robert S. Martin) Six or seven years ago I found the concepts quite interesting, and in the most interesting parts I even made detailed analyses.Design and architecture, programming paradigmsandPrinciples of module design and component separationBut that was before the channel started. So today, I decided to correct this misunderstanding and share this book, in which Uncle Bob emphasizes the importance of sharing responsibility and independence from frameworks, databases and user interfaces. Uncle Bob does this very ultimatum, which greatly undermines faith in his approach. The key ideas are the following: Dependency ruleSource code dependencies should point only inward, in the direction of high-level policies. This creates a system in which business rules do not depend on technical details. Architectural layering: when we implement this rule, we have separate layers. - Entities (substance) Main business objects and corporate business rules - Use cases (utilization) business rules of a particular application. It's funny that this term comes from UML, which is one of the types of diagrams I'm talking about. told earlier

• Interface adapters (interface adapters) - controllers, presenters and gateways
• Framework & drivers (frameworks and drivers) External tools, databases, UI frameworks This architectural approach is close to hexagonal architecture. (hexagonal architecture) or ports and adapters and onion architecture (onion architecture). It also actively incorporates the principles of SOLID, especially the dependency inversion principle, on which the entire layering and dependency rule are built. Bob says architecture should be “screaming” about its purpose – when looking at a codebase structure, it should reflect the business domain, not the technical details.

In terms of applicability, clean architecture is most useful in the following scenarios: Complex or long-lived applications where support is critical Systems where the domain model decided to separate and use the DDD style (domain driven design) Projects that require a clear separation between business logic and infrastructure It helps build systems that can evolve over time to meet changing business needs, and provides the flexibility to replace frameworks, databases, or UI technologies with minimal impact on core business logic.

This approach is deservedly criticized for Excessive complexity for small or simple projects with straightforward requirements Excessive layering and overlapping of interfaces without obvious advantages, leading to “interface abuse” Excessive template code and abstractions that make it difficult to understand the system Excessively steep learning curve for engineers and rigorous discipline for proper implementation Slowed initial project development due to preliminary design efforts Low productivity of the final decision due to excessive abstraction

Overall, I’ve seen approaches to using Clean Architecture to improve code quality in existing projects, but I wasn’t actively writing code myself when Uncle Bob revealed his concept to the world. That’s why I can’t appreciate first-hand how good apps are with it:) But it seems to me that this is like with any approach - you can do well, or you can blunder. Pure architecture is no exception.

#Architecture #Software #Engineering #DistributedSystems #SystemDesign