Distributed Architecture

We have already learned the following four facts:

1. A software product is a set of programmed use cases, and the use case isolation property tells us that the functionality of each use case can be programmed independently of any other use case.

2. There is an "application use case" - a very special use case that ties the use cases together, controlling the movement of the entire business process flow from the start of the business process to the end, moving it through the use cases according to business rules.

3. A software product requires a set of different logics (state logic, business logic, data processing logic, and data access logic) to perform different actions when the business process moves from one state to another, because the responsibilities of each such logic are unique. The uniqueness of each logic tells us that the functionality of each such logic can be programmed independently of any other logic.

4. There is a non-functional architecture that does not reflect the functionality of the business process, but supports it by providing the underlying infrastructure for exception handling, logging, communication between application components, etc.

As a result of these four facts, we have created the following view of the software product:

The figure above reflects our definition (which we gave earlier) of a software product as a set of independent functional architectural components, logically grouped into use cases and various logical layers, served by components belonging to a non-functional architectural layer.

Let us emphasize this fact once again: “a set of independent functional architectural components” means that each such component can be designed, programmed, tested independently of each other, and, moreover, deployed independently of any other component . The bolded part of the last statement means that the entire software product can be represented as a set of microservices hosted on a local network and/or on the Internet:

The fact that the functional architectural components are independent gives us the freedom to deploy them as microservices in any combination we need. For example, by grouping components by application layer:

Or by grouping components by use case:

The minimal deployment unit of such a microservice contains use case components, “Application” use case components, and non-functional architecture components. For example, the following figure shows the deployment unit if we decide to deploy the components of "use case i" belonging to the "state logic" layer of the application as a standalone microservice:

To achieve such incredible flexibility, the software product must be structured in a specific way:

· The entire product structure must be divided into use cases

· Use case components must be grouped into software layers

· Business domain components must have no knowledge of NFA components

· The NFA layer must be designed to support deployment as a microservice natively

· A DNS server must be in place to combine a set of microservices into a distributed software product

Table of Content Software Architecture Next: Use Cases Architecture