Architectural patterns - A high-level view
In an earlier article, I gave an example that a poorly architected bridge may not stand some unusual floods if subjected to them in the future, even though at the time of the bridge project handover, it may look spic-and-span.
A software application solution may do what it intends to do during handover. However, a poorly architected or poorly designed solution may not stand the test of time and stress if subjected to additional requirements and modification or may not stand maintenance arising from some future error and the like, as such complex applications must have architectural and design considerations.
Luckily there are always thought leaders who work for the good of the software developer community, and time and again, they come up with widely accepted architectures and design patterns that have stood the test of time and even bad programmers.?
As an authentic software developer, you will need to know that you just don’t write software anyhow.
We can say that you have an option to learn by trial and error, for example, when building complex systems, why one way of writing your software might prove to be messy and chaotic in the future, especially with planned or unplanned additional features. But is that the best approach, to learn by mistake? What if the error is too costly?
Many software applications have sometimes reached a point where they could not realistically be maintained anymore because of bad architecture and design earlier on.
To have some versatility and stability in the midst of complex requirements, there are many schools of thought and principles that, by common wisdom or thought leadership from others, have been adopted by the software engineering?industry in general.
Admittedly I have grouped them very loosely here. One architecture or school of thought is not necessarily an alternative to another, as listed here. Moreover, one principle or thought process may not be in the domain that another is trying to solve, purport, or advocate. Still, these are areas where you’ll need to know that they at least exist, and be sure to apply those principles wherever they fit their purpose.
Let’s briefly look at a few of them below:
Domain Driven Design (DDD)
Domain Driven Design?is a software development?approach that utilizes and builds upon the Object Oriented programming approach I briefly described in a previous article. But before expounding on the DDD?approach to software development, we need first to understand what the ‘Domain’ means, which is central to this approach.
Domain explained
A dictionary definition of the domain is: “A sphere of knowledge or activity.” So let's borrow a leaf or two from that. First, we will see that a domain within the context of software development?naturally refers to the subject area in which the software application solution intends to operate.
So if we use the dictionary definition, we can say that the domain is the ‘sphere of knowledge and activity ’ during application software development, which the application solution logic??revolves around.”
In your software development course, you will see the term domain used frequently. For example, you will hear of a domain layer or domain logic, which may be better known to many software developers?as business logic.
The business logic?of an application refers to the higher-level rules for how business objects interact to create and modify modeled data.
Domain Driven Design explained.
We cannot talk about DDD?without attributing it to a person who was one of the pioneers of the concept and introduced it in his 2004 book, ‘Domain-Driven Design: Tackling Complexity in the Heart of Software ’; Eric Evans.
Domain-driven design expands on and applies the domain concept.
DDD?helps to ease the development of complex applications by connecting related pieces of software into a model capable of evolving all the time.
There are three main principles that DDD?focuses on, and that include:
DDD?has a few standard terms that you will find helpful when describing and discussing DDD practices:
Context - The setting or environment in which a word or statement appears determines its meaning. Statements about a model can only be understood within a context.
Model - A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
Bounded Context?- A description of a boundary (typically a subsystem or the work of a specific team) within which a particular model is defined and applicable.
Domain Specific Language?(DSL) - is a language structured around the domain model and used by all team members to connect all team activities with the software application.
Advantages of using DDD
DDD?improves flexibility - Since DDD is heavily based on object-oriented analysis and design concepts, nearly everything within the domain model will be based on an object. It will, therefore, be entirely modular and encapsulated. This allows for various components, or even the entire system, to be altered and improved regularly and continuously.
DDD?eases communication- with an emphasis on establishing a common and ubiquitous language related to the domain model of the project (DSL), teams will often find contact throughout the entire development life cycle to be much easier.
Typically, DDD?will require less technical jargon when discussing aspects of the application since the ubiquitous language established early on will likely define simpler terms to refer to those more technical aspects.
Clean Architecture
This approach to building complex enterprise applications was coined by a well-known and influential American software developer, fondly known as ‘Uncle Bob’, but formally called Robert C. Martin, and was presented in his book called Clean Architecture: A Craftsman's Guide to Software Structure and Design, and this book is well worth the read, I’d recommend it to the more senior readers, in terms of experience in software development.
Or, if you find it hard to understand, I have a simplified book in my series, to be released soon, that tackles architecture and design patterns that go through and digests the concepts herein.
There’s a lot that 'uncle Bob' discusses in the book as a build-up to what he advocates, as a summary, that clean architecture should be:
When building a system, always consider the independence of different parts of the system. For example, you want to be able to plug out a MySQL?database and replace it with a Microsoft?SQL?Server database, without significant problems, in a system, should you come to a point where you need to do that.
Situations like this do come about. For example, if at any point you feel that hosting a MySQL?database in the cloud is proving to be too expensive for the business and you want to try another database implementation.
For this article, it will suffice to be aware of the ‘clean architecture, but in the next section, let’s look at one of the most widely adopted architecture for corporate institutions in the past, called Service Oriented Architecture?(SOA). It refuses to die naturally because many big corporations are still stuck with it. If in the future you happen to work in large corporate institutions that started some time back as I do now, you will have to work with SOA, and therefore it’s worth the introduction. So I’ll introduce it next:?
Services Oriented Architecture (SOA)
At this point, Service Oriented Architecture?(SOA) is becoming a legacy architecture a bit more and more. However, I have included it because most of the traditional big corporations are still using this, and if you are going to work in corporate software development, you will need to know what SOA is.
领英推荐
A modern and more popular replacement for this is the Microservices architecture, which I will briefly introduce in one of the sections below.
A Service Oriented architecture?is an architectural pattern in which software application components provide services to other members via a communications protocol, typically over a network. The principles of service orientation are independent of any product, vendor, or technology.
SOA?makes it easier for software components over various networks to work with each other.
Web services?built per the SOA?architecture tend to make them more independent. We will discuss web services more in?a later article, so please follow my page for updates.
Web services?themselves can exchange data with each other. Because of the underlying principles on which they are created, they don’t need any human interaction and also don’t need any code modifications.
This non-interference in itself ensures that the web services on a network can interact with each other seamlessly.
Event-driven architecture
An event in software development?terms does not differ from an event as you know it in the natural world.
An example event in software development?would be that ‘ a user has just abandoned their shopping cart’ in an online shopping system.
At that point, you want to be able to raise an event and possibly trigger some action internally, for example, offer the user a discount, send them an email, or indeed on to their browsing screen.
That process forms the gist of event-driven programming. With events being a common phenomenon, there’s an Event-driven architecture that was coined as a standardized way of dealing with events in a system.
An event-driven architecture enables software applications to respond to events with an action or several actions as the events happen.
You may have heard of the term batching. In more traditional approaches, that’s what developers did (piling up entities and processing them in a ‘batch’ - in one go), or some still do until now, i.e., process some data or operations in batches.
Nowadays, batching?and polling applications are becoming obsolete and being replaced with immediate processing as soon as an event is raised. As a result, event-driven processing is becoming faster and more efficient in this demanding world.
Event-driven architecture creates, detects, consumes, and reacts to events. Standard terms that you will find helpful to know in event-driven architecture include publishers, subscribers, sources, and sinks.?
You can create and respond to many events in real time with a well-designed and scalable(able to proliferate) event-driven architecture.
An event-driven architecture is particularly well-suited for loosely coupled software, such as microservices, which I will introduce in the next section.
?The event-driven architecture is versatile because it works well with unpredictable, non-linear events.
Everyday use cases for event-driven architecture
IoT?applications, fraud detection, payment processing, website monitoring, and real-time marketing make perfect use cases for event-driven architecture, as they are heavy on events.
Event-driven architectures are prevalent for microservices-based software applications because microservices perform particular tasks, which are often based on the occurrence of some event. Therefore, event-driven architectures often form the backbone of microservices. I will explain microservices briefly in the following section.
Microservices architecture
The microservices?architecture is a software solution development approach where a set of individual software applications designed for a limited scope of purposes (referred to as microservices) work together to form a more comprehensive solution.
The microservices?approach is not exactly new, as it borrows its main concepts from service-oriented architecture (SOA), which I introduced in an earlier section. Some of the common concepts with SOA include being modular and having a separation of concerns.
We can compare the microservices?architecture can be compared to a manufacturing assembly line, where each microservice is like a station in the assembly line. The same applies to microservices, just as each station is responsible for one specific task.
Each station and microservice are an “expert” in its given responsibilities, thus promoting efficiency, consistency, and quality in the workflow and the outputs.
Contrast that to some manufacturing environment where each station is responsible for building the entire product itself, instead of assembly line stations. We can compare the manufacturing environment to a software application, described as a monolith because it performs all tasks within the same process.
How the Microservices Architecture Works
Microservices?architecture is a design approach in which each microservice is just a tiny piece of a more effective overall system solution.
Each microservice performs a specific and bounded scope task contributing to the result for the whole system solution.
Microservices' advantages over a monolith?
Microservices?architecture has clear advantages over monolithic architecture for several reasons. First, microservices are easier to build because of their smaller size and, consequently, easy to deploy and scale, as more Microservices can be added to any step to run in parallel.
Microservices are easier to maintain because of their small size as well. Troubleshooting when something goes wrong in a running system becomes easy. You can stop one microservice while the other microservices?can continue to run, which can also be an advantage to your system users.
Microservices represent a new way of architecting large-scale systems that could otherwise be more difficult to manage in traditional monolithic architecture.
Microservices architecture example use cases
System solutions that involve an extensive data pipeline are good candidates for the Microservices architecture. For example, a reporting system on a company’s retail store sales. Each step in the data preparation process would be handled by a microservice: data collection, cleansing, normalization, enrichment, aggregation, and reporting.
Next, in my article series, I will talk about design patterns... follow this page for a comprehensive dev guide.
Information Technology and Science teacher
2 年Very useful and well said.