There are only three** things one truly needs know about software architecture. Everything either flows from these or are superfluous (with the exception of temporal considerations like events, asynchrony, streaming and queuing).
- Slice vertical complexity into tiers
- Slice horizontal complexity into modules
- Make the interfaces between these things as language-agnostic as possible
Instead of judicious, case-by-case use of these principles, today we have an entire taxonomy of patterns and architectures, constantly mutating, competing, growing or going extinct. Each one requires a developer to think in its increasingly cult-like jargon: models, views, controllers, reducers, immutables, actions, action creators, decorators, mediators, visitors, delegates etc. For each architecture, we have different species of frameworks, each with its own dialect of the jargon, its own way of thinking and its own sect of believers, meticulously studying and faithfully reproducing the architecture’s ideals within their own applications. The basic principles are forgotten; ten lines of glue code are needed to hold together and marshal the one line that actually does the work. Architecture becomes bureaucracy, in a state of affairs reminiscent of Execution in the Kingdom of Nouns.
As a specialized field, software engineering cannot not have jargon — front ends, back ends, APIs, modules, components, libraries. And as a field that deals with diverse problems, we cannot have a single architecture that can be applied to all systems and applications. But the line must be drawn somewhere.
Consider the canonical example of an online bookstore. The nature of the application necessitates three horizontal tiers: the front end (runs on browser), the database, and the “back end” that sits between the two and does the work (unless, of course, you’re comfortable with connecting your front end to the database directly). These will be the initial tiers.
Now the data and the functionality of the application can be sliced vertically — users, catalog, orders etc. These slices can be the basis for modules within each of the tiers.
Communication between tiers/modules should use standardized, language agnostic formats as much as possible — e.g. JSON/BSON/XML over HTTP as opposed to some sort of remote method invocation; SQL as opposed to some proprietary data access mechanism; in some cases, message passing between modules instead of direct function calls.
If the application is so large that even a single module inside a single tier is still too complex, you can repeat the process very carefully. Perhaps the front end can be horizontally sliced into a view tier and a view-agnostic, backend client tier. Note that I don’t need to extract “microservices” from the backend — microservices are basically modules with programming language agnostic interfaces.
If you follow this process on the basis of need and end up with something that looks like MVC, there is no problem. The problem arises when you jump directly into an architecture that has models, views, controllers, initializers, adapters (think Ember) or actions, action creators, reducers, views, view controllers, stores (think Flux) and god knows what else.
Let’s return to vertical and horizontal slicing with clean interfaces between the slices as the basis of architecture. What we call those slices is of secondary importance to what they are and what they do.
** I have purposely left out a possible fourth: extract repetitive/reusable code into libraries. I think we may have over-focused on that area in over the past 10–15 years.