Software Engineering and Architecture

• Separatoin of cencerns
• They all chieve this separation by dividing the software into layers. Every concept for clean architecture has at least one layer for business rules, and another layer for user and system interfaces.

• Independent of frameworks: The architecture does not depend on the existence of some library of feature-laden software. This allows you to use such frameworks as tools, rather than forcing you to cram your system into their limited constraints
• Testable: The business rules can be tested without the UI, database, web server, or any other external element
• Independent of the UI: the UI can change easily, without changing the rest of the system. A web UI could be replaced with a console UI, for example, without changing the business rules
• Independent of the database: You can swap out oracle or SQL server for mongo, BigTable, CouchDB, Blockchain or something else. Yout business ruls are not bound to the databse.
• Independent of any external agency: In fact, your business rules don't know anything at all about the interfaces to the outside world.

The overriding rule that makes this architecture work is the dependency rule: Source code dependencies must point only nward, towards hogher-level policies. -> Nothing in an inner circle can know anything at all about something in an outer circle.

• Enterprise business Rules (Entities)
  • Entities encapsulate enterprise-wide critical business rules
  • Entities encapsulate the most general and high-level rules
  • Important: They are the least likely tho change when something external changes
  • If you don't have an enterprise and are wrtiting just a single applicatoin, then these entities are the business objects of the applicatoin
• Application Business Rules (Use Cases)
  • The software in the use cases layser contains application-specific business rules. It encapsulates and implements all of the use cases of the system.
  • Use cases orchestrate the flow of data to and from the entities, and direct those entities to use their critical business rules to achieve the goals of the use case.
• Interface Adapters
  • Adapters that 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
  • GUI: It is this layer, for example, that will wholly contain the MVC architecture of a GUI, i.e. presenters, views and controllers. The models are likely just data structures that are
  • Database: For example, if the database is a SQL database, then all SQL should be restricted to this layer
  • Any other adapter necessary to convert data from some external form, such as an external service, to the internal form used by the use cases and entities
• Frameworks & Drivers
  • Outermost layer: Glue code to connect UI, databses, devices etc. to the inner circles
  • Composed of frameworks and tools such as the database and the web framework
  • Generally you don't write much code in this layer, other than glue code that communicates to the next sircle inward

Write high-level abstractions for everything that is not your core business domain, and don't let secondary component concepts leak into your business domain.