What Is Wrong With The Usual Architecture?

Photo by Michał Parzuchowski on Unsplash

A system without detectable software architecture is a Big Ball Of Mud.

As we have already discovered, systems with little or no discernable architecture resist change. These systems are rigid—we must make many modifications to shoe-horn in a new feature. When everything is dependent on everything else, another problem will also be present—fragility. Making a change in one area will generate bugs in unrelated locations. It’s like turning on the kitchen light, and your bed is on fire!   

Such systems—lacking overall architecture—miss out on Modular Pluggability. That is, the ability to quickly and with relatively little effort unplug and replace entire subsystems. Cool!

That much we have already discovered on our stroll through Software Architecture.

However, I usually see another problem with systems that are, at first glance, fairly well structured: The core business logic is dependent on many components (projects/assemblies in .NET). For example, the business logic would reference database projects as well as delivery-specific HTTP or web components.  

Why is this a problem? 

Business logic is the most stable part of a system. As a rule, a stable component should not be dependent on a volatile component. Having something stable depend on something unstable makes the stable thing unstable too. 

Abstractions—like high-level business logic—should not be dependent on detail (like database or web)—they should be dependent on other abstractions. This is simply a restatement of SOLID’s Dependency Inversion Principle. 

In the illustration below, the business logic references the more volatile data layer. Consequently, business logic will be affected by changes in how data is stored and retrieved.

OK. But what’s the solution? 

We let business logic stand by itself—it’s the centre of the application. 

Business logic does not reference any mechanisms—not database or web, remote services or mobile or any such detail.

Mechanisms plug into business logic, not the other way around—the business logic should not care whether our database is Mongo DB, Oracle, reading and writing to a file or a remote service, like SAP.

It’s much better for volatile detail to reference stable business logic than the other way round.

So, as a rule, architect your systems so that business logic remains independent of mechanisms and detail.