Quotes from Robert C. Martin

The dilemma for software developers is that business managers are not equipped to evaluate the importance of architecture. That's what software developers were hired to do. Therefore it is the responsibility of the software development team to assert the importance of architecture over the urgency of features.

ENTITIES Entities encapsulate enterprise-wide Critical Business Rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn't matter so long as the entities can be used by many different applications in the enterprise.

Remember, as a software developer, you are a stakeholder. You have a stake in the software that you need to safeguard. That's part of your role, and part of your duty. And it's a big part of why you were hired.

A good architecture will allow a system to be born as a monolith, deployed in a single file, but then to grow into a set of independently deployable units, and then all the way to independent services and/or micro-services. Later, as things change, it should allow for reversing that progression and sliding all the way back down into a monolith.

For example, maybe you like Spring. Spring is a good dependency injection framework. Maybe you use Spring to auto-wire your dependencies. That's fine, but you should not sprinkle @autowired annotations all throughout your business objects. Your business objects should not know about Spring. Instead, you can use Spring to inject dependencies into your Main component. It's OK for Main to know about Spring since Main is the dirtiest, lowest-level component in the architecture.

Software architects are, by virtue of their job description, more focused on the structure of the system than on its features and functions. Architects create an architecture that allows those features and functions to be easily developed, easily modified, and easily extended.

A good architecture protects the majority of the source code from those changes. It leaves the decoupling mode open as an option so that large deployments can use one mode, whereas small deployments can use another.

Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work.

We've all looked at the mess we've just made and then have chosen to leave it for another day. We've all felt the relief of seeing our messy program work and deciding that a working mess is better than nothing. We've all said we'd go back and clean it up later. Of course, in those days we didn't know LeBlanc's law: Later equals never.

USE CASES The software in the use cases layer contains application-specific business rules. It encapsulates and implements all of the use cases of the system. These 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.

Paradigms are ways of programming, relatively unrelated to languages. A paradigm tells you which programming structures to use, and when to use them. To date, there have been three such paradigms. For reasons we shall discuss later, there are unlikely to be any others.

Databases should usually not be considered as a major factor of the design and implementation.

structured programming, object-orient programming, and functional programming.

First, let's consider the notion that using services, by their nature, is an architecture. This is patently untrue. The architecture of a system is defined by boundaries that separate high-level policy from low-level detail and follow the Dependency Rule. Services that simply separate application behaviors are little more than expensive function calls, and are not necessarily architecturally significant.

Structured programming imposes discipline on direct transfer of control.

During this design process, we rarely considered whether we were performing analysis, design, or implementation

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

Functional programming imposes discipline upon assignment.

Leave the campground cleaner than you found it.

Don't comment bad code—rewrite it." —Brian W. Kernighan and P. J. Plaugher1

We develop features before infrastructure and frequently show those features to stakeholders.

Each of the paradigms removes capabilities from the programmer. None of them adds new capabilities. Each imposes some kind of extra discipline that is negative in its intent. The paradigms tell us what not to do, more than they tell us what to do.

Dependent Functions. If one function calls another, they should be vertically close, and the caller should be above the callee, if at all possible.

Ward's principle: "You know you are working on clean code when each routine turns out to be pretty much what you expected.