photo source

The 4+1 view model describes an application’s architecture using four views, along with scenarios that show how the elements within each view collaborate to handle requests

Includes the result of the build process that can be run or deployed such as a Java JAR or Node.js Package. These artifacts interact with each other in the form of a composition or dependency relationship.

The Monolithic Architecture Style​

Let's extract the definition of monolithic architecture from an example. Imagine you are invited to develop an enterprise application for managing music concerts ticketing, One of the requirements is to access the system from the browser and a mobile native application. SO the application will handle HTTP requests, execute a function and access a database to persist the data. One of the design options we may have is to create different components each one is responsible for a specific business logic (event subscription, payments, ticket editing ...). if we choose to develop with the java programming language and the spring framework, we'll have one application with many modules interconnected and coupled to accomplish the job. But what about the deployment? what type of build output will generate and how to deploy it into a production environment. The answer is we will generate a single Java WAR file.

The monolithic representation of our example application (Music Event Application) where we can distinguish bounded functions of the system but all in one artifact

This is what monolithic architecture is about to define the output of your source code as one piece that you can easily:

• Deploy (push or put into the production environment, or any other environment such as development or staging)
• Scale (run multiple instances of the application in response to increasing traffic)
• Debug (in case of non-normal behavior of the system you can explore the logs, check the config, and so on to find the error, all these things are on the same process)

• Question: Now the system is up and running, but a new feature is required which needs to update the payment provider within our application, how can we achieve that?
• Answer: we have to update the source code, re-build the whole application, think of a deployment strategy to ensure service continuity of our application.

In the context of our monolithic application, many drawbacks are rising while changing a small piece of the system:

• Even though the change concern only one part of the system, this one becomes indivisible and decoupled, the build and deploy process is slower because all the source code should be re-build to generate the new artifact (Java WAR file)
• The whole system is developed with one stack which limits the on-boarding of other developers with different backgrounds
• Less re-usability of the components.
• Increasing the artifact (build output) volume.
• Reliability as one bug in the ticket editing component can cause the whole system to shut down.

In the next section, we discuss the alternative and how microservices address many of the drawbacks of monolithic and bring new added value but also some very challenging points to handle.

The Microservices Architecture Style​

Microservices architecture style organizes the application as a set of loosely coupled, independently deployable services, Together these services deliver the functional and business features of the system we want to build. Let's continue with our Music Event Application example and try in the above illustration to define its microservices architecture:

The Microservices representation of our example application (Music Event Application) where 3 services communicate through HTTP using REST

As we can observe in the illustration each service run in an independent process and also could have its database(recommended), Notice also how these services communicate to each other, in this example, I suggest using the REST API through HTTP, but this is not the only communication option we can have, there are more such as messaging using a message broker.

Let's tackle with further detail the microservices inter-communications in a dedicated article, so far and the rest of this document we will use REST as a reference.

What is a service?​

As the word service is a most recurrent when we explore the microservice architecture, Here is a definition:

A service is an independent deployable application or software component that provides a set of functionalities accessible through an API. Service has its own logical architecture, Hexagonal architecture may fit many use-cases, In addition a service can be developed with its specific technology stack that may differ from other services' technology stacks in a microservices architecture

read more about Hexagonal Architecture and alternatives in this article

What is loosely coupled Services and why they should?​

Two services are loosely coupled if changes in the design, implementation, or behavior in one won't cause change in others. In a Microservices architecture, the coupling will happen when a change in one enforces an almost immediate change to one or more microservices that collaborate with it directly or indirectly.

While designing Microservices architecture, to make the services the less coupling possible, consider the following points:

Database sharing​

the data storage is a microservice implementation detail that should be hidden from its clients (usually other microservices). If Microservice A needs to access data of Microservice B, B should provide an API that A will use to consume the needed data

Code Sharing​

By definition, microservices do not share codebase, but we may want to avoid redundancy by sharing dependency libraries and end up needing to update frequently in response to that libraries' client's change requests. So shared code should be as minimum as possible. A good practice that may seem strange at glance is to duplicate code so each service has its copy, so we need to update the library to match Service A requirements, Service B remains un-impacted

Synchronous Communication​

In a Microservice architecture, services cooperate to accomplish the job, so they need to communicate either asynchronously or synchronously where the service caller expects a timely response from the callee service might even block while it waits. To address the potential response latency, we can integrate a caching mechanism or implement the circuit breaker pattern to avoid cascading failures. These two options could help remediate the system quickly, but for the long term, the best alternative is switching to asynchronous communication by using a messaging broker like Apache Kafka, So services can cooperate by publishing and consuming messages.

When it comes to designing the next-generation software, relying on a strong and reliable architecture helps a lot, In recent decades, much great software conquered the market and is serving millions of users while scaling up and down to reduce cost and energy or respond to an increasing number of requests. Microservices Architecture is part of other practices and engineering designs behind thanks to its benefits, below is a non-exhaustive list:

• Independent development: microservices can be developed in isolation to accomplish a defined functionality
• Independent deployment: microservices can be deployed individually and independently in any environment (cloud, on-premise, managed infrastructure)
• Fault isolation: if one service fails, the system remains up and only the functionality provided by that stopped microservice will be impacted
• Technology stack: different programming languages, frameworks, and technologies can be used to build the same software, usually a SaaS
• Individually scaling: each service can scale as per need, is not necessarily to scale the whole system as is the case of monolithic based application

Despite the number of advantages Microservices Architecture is bringing, choosing it over Monolithic Architecture relies upon on the context, the application domain (banking, delivery, e-commerce, ...) and scope (either is a lightweight application or a complex evolving application), your organization software engineering capabilities and culture.

---

• Software Architecture Definition by Wikipedia
• The “4+1” View Model of Software Architecture by Philippe Kruchten
• Advancing the Practice of Software Architecture by Software Engineering Institute
• Microservice Patterns by Chris Richardson

photo source

The 4+1 view model describes an application’s architecture using four views, along with scenarios that show how the elements within each view collaborate to handle requests

The layered architecture style​

This is my first architecture style I've discovered 10 years ago thanks to my java enterprise application course teacher, Ths idea consist of organizing the elements of an application into layers. Those elements could be java classes grouped by the responsibility type they manage and respect the rule that each layer should depend only on the layer below it, Another version also tolerate that a layer can depends on the any of the layers below it.

Even though we can apply this architecture style to any of the 4 model view we've seen above, It is most likely to be used in the logical view as follows:

• Presentation layer: groups classes & interfaces that handle the UI interactions, Such as desktop application UI that handles user interactions like Click, Press, etc...
• Business logic layer: contains classes where we implement the business logic of the system. For example classes that calculate the shortest route for delivering merchandise from stock house to customer.
• Persistence layer: contains interfaces and classes that interact with database or file system. For example classes that communicate with a MySQL database.

In the above figure, we illustrate the 3 tier architecture for a java application, classes of the same layer are grouped using packages.Note that architecture is beyond any programming language, so for example in case of a C# application we group classes in namespaces instead of packages for java.

The years go by and the software development community began to recognize some drawbacks of N Tier architecture, below we list some of them:

• Single Presentation Layer: With the evolution of the web and mobile applications, many systems provide the same functions, For example a desktop application for logistics providing the feature of calculating the shortest route and cost of a delivery, While the business logic remains the same, the interactions with the system are evolving with mobile and web users.
• Single Persistence Layer: Modern systems needs to interact with many and/or different storage systems rather than one database.
• Layer dependencies: As the business logic depends on the persistence one, we are prevented from testing the business logic in an isolation.

These disadvantages lead to an alternative architecture style we present next.

The Hexagonal Architecture Style​

This architecture style organizes the logical view in a way that puts the business logic at the center. In contrast to the layered architecture that has a presentation layer, we have here one or more inbound adapters that handle requests from the outside by invoking the business logic. The same applied to the persistence layer, the application has or more outbound adapters that are invoked by the business logic and invoke external applications. The main characteristic of this architecture style is that the business logic doesn't depend on these adapters, instead they depend on it. The Business logic has one or more ports.A port defines a set of operations and is how the business logic interacts with what's outside it. For example in java these ports are a Java Interface. we distinguish inbound and outbound ports. An inbound port is an API exposed by the business logic, which enables it to be invoked by external applications, for example a REST API.An outbound port is how the business logic invokes external systems like Database Access Repositories.

Like the ports there are inbound and outbound adapters. An inbound adapter handles requests from the outside world by invoking an inbound port. For example in the case of a Java Web Application using Spring framework, An inbound adapter is a Rest Controller that will invoke inbound port exposed by the business logic. An outbound adapter implements an outbound port and handles requests from the business logic by invoking an external application or service.An example of an outbound adapter is an Event Publisher to Kafka or any other Event streaming system.

The Figure above shows an example of the hexagonal architecture where the business logic has one or more adapters to communicate with external systems

Let me remind you that decoupling the business logic from the presentation and data access is the important benefit of the hexagonal architecture style. This is very useful also when it comes to testing as you can use TDD easily as you can test your business logic in an isolation.It also defines new model for the modern applications where the business logic can be invoked by multiple adapters each one of them invokes an external system.

The Hexagonal Architecture style is well fit to define the architecture of each service in a microservice architecture.

Both the layered and hexagonal architectures are a set of constraints and rules on how elements within the logical view are connected and how they communicate.

---

• Software Architecture Definition by Wikipedia
• The “4+1” View Model of Software Architecture by Philippe Kruchten
• Advancing the Practice of Software Architecture by Software Engineering Institute

photo source

The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. by SEI

We can decrypt the above definition as structuring a system as a whole recessed block into parts connected, complementary and modular. The more these parts are decoupled and can work independently, and communicate to each other effectively the more our architecture will fill its mission to ensure a maintainable, extensible and homogeneous system.

The 4+1 view model of software architecture

Like a building, there are different plans and maps that can describe different the different perspectives of that building, we have the electrical, plumbing, structural and others. This is exactly how the 4+1 view model defines software architecture in the paper published by Phillip Krutchen

The 4+1 view model describes an application’s architecture using four views, along with scenarios that show how the elements within each view collaborate to handle requests

Each of the four views has a well-defined purpose as detailed below:

Logical View​

It consists of the source code written by developers, in the context of an oriented programming language like Java, the elements are classes and packages, in addition to relationships between them such as inheritance, association, and composition...

Implementation View​

Includes the result of the build process that can be run or deployed such as a Java JAR or Node.js Package. These interact with each other in the form or a composition or dependency relationship.

Process View​

Refer to the process holding and running either in virtual machines or containers like docker, relations between them is called inter-process communication.

Deployment View​

Represents the map of the physical or virtual machines where the system is executed and running, also describes the communication at level through the network. For example this view can be a VPC with all the routing configuration inside this network and between it and the internet.

Why an application architecture is relevant?

An application come to life with the purpose of solving a problem, to do so it needs to fulfill two types of requirements, Functional requirements that defines what the application should do, Previously defined in the form of specifications, with the agile edge we define them as user stories, use cases, or events. we can start coding immediately and produce an application that respond to these requirements without thinking about architecture. But when it come to develop a reliable, maintainable and extensible system, Architecture is our core activity because it helps us answer questions regarding how the system behaves with millions of users at the same time, security threats and delivery time. Architecture meets quality requirements.

Architecture Styles

I found the definition given by David Garlan and Mary Shaw in their publication titled An Introduction to Software Architecture an amazing reference to understand the concept of architecture styles and how it can be view in the field of computing systems.

An architectural style, then, defines a family of such systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined. These can include topological constraints on architectural descriptions (e.g., no cycles). Other constraints—say, having to do with execution semantics—might also be part of the style definition.

Follow are the questions shared by these two pioneers in the discipline of software architecture, answering these questions will remarkably help define the architecture that fit for the system we're building:

Given this framework, we can understand what a style is by answering the following questions: What is the structural pattern,the components, connectors, and constraints? What is the underlying computational model? What are the essential invariants of the style? What are some common examples of its use? What are the advantages and disadvantages of using that style? What are some common specializations?

in the next part, let's explore some of the most known architecture styles Logical View

---

• Software Architecture Definition by Wikipedia
• The “4+1” View Model of Software Architecture by Philippe Kruchten
• Advancing the Practice of Software Architecture by Software Engineering Institute