Clean Architecture: A Craftsman's Guide to Software Structure and Design

by Robert C. Martin

The measure of design quality is simply the measure of the effort required to meet the needs of the customer. If that effort is low, and stays low throughout the lifetime of the system, the design is good. If that effort grows with each new release, the design is bad. It’s as simple as that.

Structured programming imposes discipline on direct transfer of control.

Object-oriented programming imposes discipline on indirect transfer of control.

Functional programming imposes discipline upon assignment.

Some folks fall back on three magic words to explain the nature of OO: encapsulation, inheritance, and polymorphism. The implication is that OO is the proper admixture of these three things, or at least that an OO language must support these three things.

OO languages may not have given us polymorphism, but they have made it much safer and much more convenient.

SEGREGATION OF MUTABILITY One of the most common compromises in regard to immutability is to segregate the application, or the services within the application, into mutable and immutable components.

Event sourcing is a strategy wherein we store the transactions, but not the state. When state is required, we simply apply all the transactions from the beginning of time.

Structured programming is discipline imposed upon direct transfer of control. • Object-oriented programming is discipline imposed upon indirect transfer of control. • Functional programming is discipline imposed upon variable assignment.

SRP: The Single Responsibility Principle An active corollary to Conway’s law: The best structure for a software system is heavily influenced by the social structure of the organization that uses it so that each software module has one, and only one, reason to change. • OCP: The Open-Closed Principle Bertrand Meyer made this principle famous in the 1980s. The gist is that for software systems to be easy to change, they must be designed to allow the behavior of those systems to be changed by adding new code, rather than changing existing code. • LSP: The Liskov Substitution Principle Barbara Liskov’s famous definition of subtypes, from 1988. In short, this principle says that to build software systems from interchangeable parts, those parts must adhere to a contract that allows those parts to be substituted one for another. • ISP: The Interface Segregation Principle This principle advises software designers to avoid depending on things that they don’t use. • DIP: The Dependency Inversion Principle

For example, Agile Software Development, Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall, 2002, http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod, and https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) (or just google SOLID).

A module should be responsible to one, and only one, user or stakeholder.

SYMPTOM 1: ACCIDENTAL DUPLICATION

This class violates the SRP because those three methods are responsible to three very different actors.

SYMPTOM 2: MERGES

Two different developers, possibly from two different teams, check out the Employee class and begin to make changes. Unfortunately their changes collide. The result is a merge.

At the architectural level, it becomes the Axis of Change responsible for the creation of Architectural Boundaries.

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

DIRECTIONAL CONTROL

Much of the complexity in that diagram was intended to make sure that the dependencies between the components pointed in the correct direction.

INFORMATION HIDING

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 LSP can, and should, be extended to the level of architecture. A simple violation of substitutability, can cause a system’s architecture to be polluted with a significant amount of extra mechanisms.

CONCLUSION The lesson here is that depending on something that carries baggage that you don’t need can cause you troubles that you didn’t expect.

The Dependency Inversion Principle (DIP) tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions.

STABLE ABSTRACTIONS