Quotes from Robert C. Martin

SERVICES The strongest boundary is a service. A service is a process, generally started from the command line or through an equivalent system call. Services do not depend on their physical location. Two communicating services may, or may not, operate in the same physical processor or multicore. The services assume that all communications take place over the network.

The primary purpose of architecture is to support the life cycle of the system. Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy.

The source code of higher-level services must not contain any specific physical knowledge (e.g., a URI) of any lower-level service.

Gather together those things that change at the same times and for the same reasons. Separate those things that change at different times or for different reasons.

The Open-Closed Principle (OCP) was coined in 1988 by Bertrand Meyer.1 It says: A software artifact should be open for extension but closed for modification.

Am I suggesting 100% test coverage? No, I'm not suggesting it. I'm demanding it. Every single line of code that you write should be tested. Period. Isn't that unrealistic? Of course not. You only write code because you expect it to get executed. If you expect it to get executed, you ought to know that it works. The only way to know this is to test it.

THE COMMON REUSE PRINCIPLE Don't force users of a component to depend on things they don't need.

if simple extensions to the requirements force massive changes to the software, then the architects of that software system have engaged in a spectacular failure.

A computer program is a detailed description of the policy by which inputs are transformed into outputs.

Architecture should reveal operation. The architecture of the system should elevate the use cases, the features, and the required behaviors of the system to first-class entities that are visible landmarks for the developers. This simplifies the understanding of the system and, therefore, greatly aids in development and maintenance.

Part of the art of developing a software architecture is carefully separating those policies from one another, and regrouping them based on the ways that they change.

software has two types of value: the value of its behavior and the value of its structure.

Policies that change for the same reasons, and at the same times, are at the same level and belong together in the same component. Policies that change for different reasons, or at different times, are at different levels and should be separated into different components.

If component A should be protected from changes in component B, then component B should depend on component A.

Architects separate functionality based on how, why, and when it changes, and then organize that separated functionality into a hierarchy of components.

THE ACYCLIC DEPENDENCIES PRINCIPLE Allow no cycles in the component dependency graph.

Transitive dependencies are a violation of the general principle that software entities should not depend on things they don't directly use. We'll encounter that principle again when we talk about the Interface Segregation Principle and the Common Reuse Principle.

The goal of the architect is to create a shape for the system that recognizes policy as the most essential element of the system while making the details irrelevant to that policy. This allows decisions about those details to be delayed and deferred.

The OCP is one of the driving forces behind the architecture of systems. The goal is to make the system easy to extend without incurring a high impact of change. This goal is accomplished by partitioning the system into components, and arranging those components into a dependency hierarchy that protects higher-level components from changes in lower-level components.

The critical rules and critical data are inextricably bound, so they are a good candidate for an object. We'll call this kind of object an Entity.1

The Entity is pure business and nothing else.

Why are Entities high level and use cases lower level? Because use cases are specific to a single application and, therefore, are closer to the inputs and outputs of that system. Entities are generalizations that can be used in many different applications, so they are farther from the inputs and outputs of the system. Use cases depend on Entities; Entities do not depend on use cases.

But then closely related concepts should not be separated into different files unless you have a very good reason. Indeed, this is one of the reasons that protected variables should be avoided.

Code at the boundaries needs clear separation and tests that define expectations. We should avoid letting too much of our code know about the third-party particulars. It's better to depend on something you control than on something you don't control, lest it end up controlling you.