TheBig Ball of Mud指的是一种体系结构,缺乏任何structural design and therefore results in complex, tightly coupled, and interdependent code.

It is, unfortunately, the most popular way to design software, and its pervasive adoption is usually unintentional. It emerges due to a general lack of understanding of architectural principles, undisciplined development practices, piecemeal growth and the accumulation of technical debt over time.

You know this kind of systems… We all do!!!

And scarily enough these systems comprise a significant portion of software in the real world! But there is an antidote to them: architectural patterns!

Anarchitectural patternis a reusable solution to a specific problem that helps define the basic characteristics and behaviour of an application. Choose the right patterns for your problem, and you can avoid reinventing the wheel and potential nasty traps that may cause trouble had you attempted to come up with a new solution.

Let’s explore seven of the most common patterns that every developer, architect, or data scientist needs to be familiar with.

The Layers Pattern is one of the most used (and abused) patterns that relies on partitioning the code into distinct and independent layers which decreases the coupling between them. Each layer is marked asclosed, which means that a request must pass through the layer right below it to go to the next layer. It also has its own responsibility which provides alevel of isolationas it enables us to modify a layer’s components without affecting the other layers.

There are many variants of this pattern, but it typically has four layers: presentation/UI layer, service layer, business logic/domain layer, data access layer. It has also been the inspiration of other major patterns e.g.MVC(Model, View, Controller).

In the Pipes and Filters pattern, each filter is responsible for a single data operation or transformation. Data isstreamedfrom one filter to the next one via pipes and operations occur in parallel. This means that a filter produces output as soon as it becomes available without waiting until all input is consumed. The filters are loosely coupled so they can be reused and reassembled to create new pipelines.

Typical usage of this pattern is the Unix piped command.

The Batch Sequential Pattern is similar to Pipes and Filters with the main difference being that the former is not streaming the data but usually writes all data to disk for the next stage to read — quite old-school :).

In a Client-Server pattern, the functionality of the system is organised into services, with each type of service delivered from a separate server. Clients access the servers to make use of theseservices.

A server is permanently active listening for clients’ requests. Once a request is received, the server opens a connection with the client over a specific protocol, processes the request and responds back. The requests are sent beyond process and machine boundaries which means clients and servers may reside on different machines.

AREST(Representational State Transfer) architecture is a client-server architecture where clients are separated from servers by a uniform interface, servers offer addressable endpoints (e.g. by a URL) and communication is stateless (there is no information or memory carried over from the previous request) via HTTP. REST APIs (Application Programming Interfaces) are the industry standard for web-based applications.

For some organisations, SOA is a stepping stone to replace monolithic applications, providing a more flexible and agile environment. It provides a group of modular services that can ‘talk’ to each other to support applications and their deployment.

The service interfaces provide loose coupling, which means that they can be called with little or no knowledge of how the integration is implemented underneath. Traditionally, SOA involves anenterprise service bus(ESB) as a means of coordinating and controlling these services.

Not all applications are suited to this type of architecture e.g. situations where strictly enforced response times are required.

The microservices architecture pattern takes the approach of building small,single-purposeandself-contained服务,相互沟通entire system to work. Each service is deployed independently, thereby providing a high degree of decoupling, and also evolves autonomously while maintaining clear interfaces/contracts with the others.

DevOps can be used to help an organisation to transition from SOA to Microservices, as the latter often operate in containers, which make them more scalable and portable.

The granularity of the APIs provided by microservices is often different from what a client needs. In these cases anAPI gatewayis implemented that is the single entry point for all clients and handles requests in one of two ways: either simply route them to the appropriate service or even orchestrating them out to multiple services.

The Event Driven architecture is the most commonasynchronouspattern which is centred around messages that describe events as well as their handling (i.e. their production, detection and consumption). Events areimmutable(i.e. they cannot be changed or deleted), and they are ordered chronologically. They are used to trigger or communicate between services in real-time (i.e. a service does not poll for updates but receives them).

Events can be published in several ways, with the two most popular being:

⇾ to amessage queuethat guarantees delivery of an event to the appropriate consumer, or,
⇾ to abroker, where an event does not target a certain recipient but access to the ‘topic’ is allowed to all interested parties (aka subscribers). Pub/Sub messaging systems are often described as anEvent Streaming Architecture.

One of the most popular practices in EDA is calledCQRS(Command Query Responsibility Segregation), which allows for using different models to update and read domain data.

Another important practice that deals with the atomicity of the transactions isEvent Sourcingwhere updates and deletes are never performed directly on the data; rather, state changes of an entity are saved as a series of events — this enables the reconstruction of the state of the application at any point in time.

All the architectures described above have one common denominator: theirdependency on the infrastructure.

In a Serverless Architecture, the cloud providers can easily manage the provisioning of servers on-demand basis. The applications are hosted in containers and are deployed in thecloud. Developers do not have to worry about planning the servers’ resources (memory, CPU, IO), or designing such a topology that results in a highly available and automatically scalable application — the cloud provider takes care of this by essentially virtualising the runtime and operational management. Therefore, such providers usually charge their customers based on the total number of requests, the frequency of requests over a specified period or the total time spent to serve all of the requests.

Serverless encompasses two different but overlapping areas:

⇾ Function as a Service (FaaS): Custom code that runs in ephemeral containers.
⇾ Backend as a Service (BaaS): Applications that significantly depend on third-party services for backend aspects (e.g. DB, cloud storage, user authentication etc).

There is no one-size-fits-all architecture that can be applied to every project so understanding the pros and cons of the architecture patterns, and some of their most common design decisions is an important part of creating the best design possible. Also it is worth noting that these patterns are not mutually exclusive; in fact, they complement one another!

I hope this article is a good starting point to your learning journey. The following matrix summarises the patterns explored above:

Thanks for reading!

I regularly write about Leadership, Technology & Data on Medium — if you would like to read my future posts then please‘Follow’ me!