Clean Architecture (Chinese Translation)

An Entity is a software object (or module) that embodies a small set of Critical Business Rules operating on Critical Business Data.

Characteristics of an Entity:

• Encapsulation: The Entity either contains the Critical Business Data or has very easy access to it.
• Interface: The interface of an Entity consists of the functions that implement the Critical Business Rules.
• Independence: An Entity is "pure business." It must be unsullied by concerns regarding databases, user interfaces, or third-party frameworks. It should be able to serve the business in any system, regardless of how data is stored or how the UI is presented.
• Implementation Agnostic: While often implemented as a class in object-oriented languages, an Entity can be any single, separate software module that binds critical data and rules together.

Screaming Architecture is a design principle where the high-level structure of a software system (its top-level directories and packages) clearly communicates the system's core business purpose or use cases, rather than the technical tools or frameworks used to implement it.

Instead of a directory structure that screams "Rails," "Spring," or "ASP," a well-designed architecture should scream "Health Care System," "Accounting System," or "Inventory Management System."

Software architecture is the shape given to a system by its builders. This shape is defined by:

1. The division of the system into components.
2. The arrangement of those components.
3. The ways in which those components communicate.

The primary purpose of architecture is not just to make a system work (which is a passive/cosmetic role), but to support the system's entire lifecycle. Good architecture aims to minimize the lifetime cost of the system and maximize programmer productivity by making the system easy to understand, develop, maintain, and deploy.

The SOLID principles are mid-level design principles used to organize functions and data structures (referred to as "classes") into modules and components. The primary goals of applying these principles are to create software structures that:

• Tolerate change: Make the system resilient to modifications.
• Are easy to understand: Improve code readability and maintainability.
• Enable component reuse: Build components that can be used across multiple software systems.

While often associated with Object-Oriented Programming (OOP), these principles apply to any grouping of functions and data, regardless of whether they are explicitly defined as "classes."

To ensure the long-term health and maintainability of an embedded product, avoid the following anti-patterns:

1. Treating all code as firmware: Do not allow all application logic to be tightly coupled to the hardware/firmware layer.
2. Hardware-only testing: Avoid architectures where code can only be tested on the target hardware. This makes the development process difficult and slow.

A clean embedded architecture separates concerns to allow for better testing (e.g., off-target testing) and long-term maintenance.

A plugin architecture is a pattern used to create scalable and maintainable systems by separating core business rules from optional or highly variable components. In this model, components like the User Interface (GUI) and the Database are treated as 'plugins' that plug into the core business rules.

Key Characteristics:

• Independence: Core business rules remain independent of the components that implement them.
• Interchangeability: Because the GUI is a plugin, you can switch between Web-based, Client/Server, SOA, or Console-based interfaces. Because the Database is a plugin, you can swap SQL databases for NoSQL or file-system-based databases.
• Isolation: Changes in a plugin (e.g., changing a web page format or a database schema) should not affect or break the core business rules.

The C4 model provides a hierarchical way to think about the static structure of a software system. It breaks the system down into four levels (though this text focuses on the three lower levels):

1. Containers: The highest level of deployment. Examples include Web applications, mobile apps, standalone applications, databases, or file systems.
2. Components: Reside inside a container. A component is defined as "a grouping of related functionality behind a nice clean interface."
3. Classes (or Code): The smallest unit, which implements the components.

Note: Whether a component resides in a separate deployment unit (like a Java .jar file) is considered an orthogonal concern to its structural definition in the C4 model.

Data streams can be split by separating different levels of policy. Instead of one monolithic component handling everything, you can divide logic into:

1. Lower-level mechanics policies: These handle the fundamental rules of the system (e.g., how a player moves through a map, how caverns are connected, and triggering raw events like FoundFood or FellInPit).
2. Higher-level policies: These manage the consequences and state (e.g., player health, winning/losing conditions). They consume the events declared by the lower-level mechanics to update the global state.

This separation allows for a cleaner flow where low-level components declare events and high-level components manage the resulting state.