Taking a step further back from the code and thinking more abstractly about designing software and services we encounter design patterns which attempt to make larger scale designs more responsive to change.
You don’t need to know these in depth but being aware of their existence and what they are trying to achieve will help you in your design process.
The patterns below are some good starting points but you will find many more if you dig deeper.
The Onion Architecture is not well known but often implemented. It is a foundational part of the more popular clean architecture (discussed later).
This Architecture relies heavily on the Dependency Inversion Principle and focuses on decoupling the business logic from other layers which is a recurring theme for building responsive architectures.
Domain Driven Design is a concept that models software based on a business domain and it’s context, working closely with business experts.
You might see how the DDD approach fits well with the Made Tech Playbook where we spend effort understanding the business context, working closely with subject matter experts.
DDD Made Simple - 8 minutes
However it’s implementation can be complicated or overkill for smaller projects.
Stop Dogmatic DDD - 7 minutes
Hexagonal Architecture is yet another approach that shares many themes from above.
The Ports and Adapters approach here is incredibly powerful for creating easily testable units of code. Using this approach you end up injecting dependancies into your units of code (e.g a class) decoupling anything outside the core application (such as a database or API).
How To Make Your App Maintainable (hint: Adopt Hexagonal Architecture) - 18 mins
A slightly different twist on the above approaches where users and their behaviour are moved to the fore.
Objects are principally about people and their mental models—not polymorphism, coupling and cohesion … but in spite of capturing structure, OO fails to capture behavior
Clean architecture is an amalgamation of a number of architecture strategies. It is an attempt to create a separation of concerns. This separation is achieved by dividing the software into layers such as decoupling UI from the Business logic or external dependancies to increase testability and changeability of components increasing your softwares responsiveness to change.
The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards.
A simple explanation that nicely explains when and when not to follow dogma based on trade offs - 15 minutes
An application and system architecture that has been well designed (and implemented) enables you to reap the benefits of other patterns such as Event Driven Architecture.
Events (as messages) can be easily transmitted among loosely coupled software components and services, an example of this might be using the Observer Pattern to notify a Search Engine that state has changed to allow instant re-indexing.