In the previous chapter we started with architectural patterns and grouped them in accordance with their structure and function into metapatterns. Now let’s traverse in the opposite direction: from topology (the structure of a system) to the patterns which describe it. We will draw and analyze a map of common system topologies and along the way outline the scope of this book.

Methodology

We will rely on our finding that any system has a characteristic representation in the abstractness-subdomain-sharding space. The amounts of a system’s partitioning along each of the three dimensions can be used as its coordinates on a map of system topologies:

Abstractness corresponds to the technical partitioning [FSA] — subdivision of a system into layers with different roles and technologies. Any use case will likely involve all the layers.

Subdomain represents the domain partitioning [FSA] — segregation of a system into modules or services that encapsulate distinct parts of the business knowledge. A use case is often localized in one or two subdomains.

Sharding is about running multiple instances (shards or replicas) of a component.

From theory to practice

Having a distribution of architectures in a 3D space sounds great, but how do we represent it as human-readable media?

There are at least the following issues:

• Many system topologies feature similar levels of segregation into layers and services, meaning that they belong to the same neighborhood on the map.
• It makes a difference if a system’s business logic or its infrastructure is subdivided because business logic comprises the bulk of the code. Therefore we cannot estimate a system’s coordinates only from the number of layers or services it contains, which means that we are limited to something like “major layering” and “minor layering” instead of numeric values.
• Sharding of many architectures varies widely and is hard to represent on a flat drawing.

As a result, the following adjustments were necessary to make the map of system topologies comprehendable:

• Sharding is omitted, transforming 3D coordinates into a flat map. Yes, much information is lost, but too much information is no information. Now the map is easier to read.
• I took the liberty of shifting topologies from their real positions to resolve overlaps.
• Even worse, I moved some of the topologies around to group similar architectures.
• Exotic (e.g. Leaf-Spine Architecture) and duplicate (e.g. Microservices) topologies are omitted.

The map of system topologies

The map contains only basic architectures which are easy to apprehend and name. Any complex system is very likely to be a combination of these simple topologies.

I somewhat arbitrarily divided the map of system topologies into five partially overlapping regions:

• Monolithic, where the bulk of the system is kept in a single component.
• Layered, with mostly technical partitioning, where architectural components are specialized (drawn in few colors which correspond to different kinds of code).
• Services with domain partitioning, meaning that each of the main components includes several kinds of code.
• Fragmented systems built of many smaller parts.
• Plugins that usually have a cohesive core and external modular layers.

This grouping allows us to study the topologies piecemeal without getting lost in their numbers and features.

Monolithic systems

In the simplest cases a project is too small for any internal structure to be justified — you can code it in a couple of hours without any preliminary design. In other cases the domain is known to be so cohesive that you cannot find good module boundaries — any internal interfaces result in much boilerplate code or degrade performance. Or there is no time left for a thoughtful design!

True Monoliths

Few system topologies are truly monolithic with one kind of system components:

• Monolith keeps everything together in a single cohesive application which makes sense for small, one-off projects. A long-running Monolith may need to handle inputs and events, for which there are several options:
  - Reactor uses a thread for each request and blocks on calls to the OS or other components. This is the simplest server-side implementation.
  - Proactor relies on callbacks that run in a single thread to achieve real-time latency and avoid locks. It is widely used in embedded programming.
  - Half-Sync/Half-Async is an internally layered approach that allocates a coroutine or fiber to each task. It is more resource-efficient than Reactor but lacks the real-time responsiveness of Proactor.
• Shards are multiple instances of a Monolith, each owning a slice of the system’s data. A client must know which shard to access either through storing its address or by querying an Ambassador Proxy library written by the team that deploys the shards. This is the architecture of choice when clients are independent from each other but the entire dataset is too large to fit in a single server.
• Replicas are instances of a Monolith with identical data used to achieve fault tolerance and high throughput. Any writes to one replica must be propagated to the other replicas:
  - With semi-specialized replicas all write requests go to a single leader instance which publishes the changes for the other replicas, called followers, to apply to their datasets. Read requests usually go to the followers, and the more read traffic there is, the more followers are deployed.
  - If all the replicas are identical, any of them can handle a write request and publish the update for the other replicas to apply. This scales write throughput but involves the chance of data conflicts when the same data record is simultaneously changed on multiple replicas. See Data Grid of Space-Based Architecture.

Monoliths with auxiliary layers

In other kinds of systems, common in server-side programming, some functionality moves to a dedicated layer while the business logic remains monolithic:

• Monolith with a database relies on an external data storage component for persistence.
• Monolith with Polyglot Persistence uses specialized databases to improve performance.
• Monolith with Backends for Frontends employs a Proxy for each kind of client to address variations in the clients’ protocols and security.
• Managed Shards run behind a single Sharding Proxy which connects each system’s client to the shard that has that client’s data thus isolating the clients from the knowledge of the system’s internal composition.
• Peer-to-Peer Mesh interconnects multiple instances of an application, acting as a distributed Middleware.

Monoliths with Plugins

A monolithic core can be extended with disposable additions:

• Plugins allow for parts of the core’s workflow to be supplied by internal or external teams, customizing the experience of the system’s users without modifications to its main code.
• Model-View-Controller and related patterns provide a presentation layer that isolates the main code from dependencies on the UI framework or network protocol, thus minimizing the effort of porting the software to another platform.
• Hexagonal Architecture keeps the entire business logic self-sufficient by wrapping every dependency with a dedicated Adapter, which not only improves portability but also helps with testing and allows for changing vendors late in the development cycle.

Underdeveloped Moduliths

If a Monolith evolves for a long time, it will likely become segmented into subdomain components, yielding a Modulith. As that process is not instantaneous, there are a couple of transitional architectures:

• Monolith with libraries involves subdomain-specific third-party components which are called by its cohesive business logic.
• Modulith with shared code has the business logic largely separated into subdomain modules which still rely on a common codebase for shared functionality.

Layered architectures

Layering enables the use of specialized technologies and third-party components while avoiding the risky subdivision of business logic. It also allows for parts of the system to differ in their qualities, placement, and scalability. All of that makes layered architectures suitable for full-featured, medium-sized projects run by one or two teams where both the speed of development and supportability matter.

Ordinary Layers

Typical layered architectures include:

• Layers of various composition, for example:
  - Entity-Control-Boundary which represent the domain model, use cases, and interface, respectively. This pattern originated in the age of complex desktop applications.
  - Domain-Driven Design decomposition into presentation (interface), application (use cases), domain (business rules), and infrastructure (communication and persistence). It targets enterprise systems.
  - Embedded systems with pairs of UI + HMI, SDK + HAL, and FW + HW implemented by distinct parties in the supply chain.
• Layers with Polyglot Persistence where the persistence layer involves multiple databases, usually chosen for their performance with specialized payloads.
• Layers with Backends for Frontends with a dedicated interface and/or application component for each kind of client when the clients differ in their protocols and/or workflows.
• Monolith with a database as a case of rudimentary layering of server-side systems.

Scaled Layers

Several layered architectures build around scalability:

• Three-Tier Architecture contains a frontend layer with an instance per system’s user, scaled backend, and non-scaled database. It exploits the physical distribution of the system to reap cost, performance, and security benefits.
• Scaled service runs multiple instances of a stateless application between a Load Balancer, which evenly distributes user requests among the instances, and a Shared Database. It is the default approach for scaling a server-side service.
• MapReduce or Scatter-Gather runs a coupled part of a calculation in a non-scaled layer while mutually independent parts are delegated to multiple worker shards.
• Managed Shards rely on a Sharding Proxy layer to connect a client to the appropriate shard. This removes the need for the client to know which shard contains its data.
• Peer-to-Peer Mesh builds a distributed Middleware layer that interconnects instances of a client application.

Other layered systems

Besides that, there are a few peculiar layered systems:

• Model-View-Presenter family of patterns features layered user interfaces which decouple the main system from a GUI or web framework with the goal of being able to easily switch to another framework version or vendor.
• Onion Architecture or Clean Architecture is a Hexagonal Architecture (see below) with a layered core structured along the ideas of Domain-Driven Design.
• Sandwich architectures are Layers with the domain logic layer split into subdomains. It is a pragmatic low effort approach to tackle complexity in quickly evolving projects that can afford several development teams. It also addresses data-centric domains.

Plugins family

Some architectures specialize in separating complex core logic from miscellaneous details to make the core independent and reusable under changing conditions. In most cases the core contains monolithic business logic but that may vary among patterns. This family of topologies is prevalent in long-living or highly customizable products whose codebases are too expensive to rewrite to address every trend or fad.

Plugin Architecture

Plugins are external components which supply predefined parts of a host component’s workflow. They may be created by the company that makes the product, often for the sake of selling several flavors with limited or specialized functionality. Or they may come from external programmers, as codecs in video players or customizations for accounting software, to extend the usefulness of a product without overburdening its core codebase.

Separated Presentation

Separated Presentation extracts the user or network interface functionality into a dedicated layer which is often further subdivided. This makes the main codebase reusable in different environments:

• The Model-View-Controller family of patterns has separate modules for platform-specific input and display output which is beneficial when there is no web or GUI framework that can provide a unified high-level user interface.
• The Model-View-Presenter family builds on top of a pre-existing platform-specific presentation layer. Most of these patterns add an intermediate Adapter between the platform-dependent code and the core application.

Control patterns

A couple of topologies originate with embedded or systems programming where it is important to abstract the business logic from the hardware components which tend to quickly go out of production and thus need to be replaced with incompatible models:

• Pedestal wraps each hardware component in a system with a dedicated driver to reduce the dependency of the business logic on hardware specifications thus allowing for the software to be reused for different hardware setups.
• Microkernel Architecture relies on an eponymous layer to mediate between resource consumers and resource producers which implement generic interfaces and thus are replaceable. This approach is surprisingly ubiquitous:
  - Operating systems are the origin of Microkernel, with user space applications competing for system resources owned by the device drivers.
  - Interpreters run user scripts in a sandbox and provide them access to installed libraries.
  - Software frameworks follow a similar approach, building a Facade to grant user code a managed access to the framework’s internal components.
  - Hypervisors, Virtualizers, and Distributed Runtimes abstract a guest operating system or applications from the platform they run on.

Hexagonal Architecture

A few architectures fully isolate business logic from its environment, resulting in great portability, simpler automated testing and improved separation of concerns:

• Ports and Adapters (the original Hexagonal Architecture) inserts an Adapter into every communication pathway in or out of its business logic core but does not specify the structure of the core itself, which makes the pattern universally applicable.
• Onion Architecture or Clean Architecture structures the core in accordance with the rules of Domain-Driven Design, limiting the applicability of this topology to enterprise systems or complex backends.

Cell

Cell is a building block of huge systems that follow Domain-Oriented Microservice Architecture or Cell-Based Architecture. It is a kind of Hexagonal Architecture with a modular and often distributed core. The internals of a Cell are hidden behind a Cell Gateway which implements the Cell’s public interface. Any outgoing communication, initiated from inside the Cell, goes through its Adapters or through Plugins supplied by peer Cells.

Services area

Partitioning a system into modules or services which match its subdomains and assigning the components to dedicated teams greatly reduces the cognitive load that the programmers face as each person needs to comprehend only the service they work on. Given that it is cognitive load that determines development speed, most large projects have service-based topologies.

However, full domain partitioning [FSA] is beneficial only when the system’s subdomains are weakly coupled along every level of their functionality, which is why many real-world topologies mix cohesive system-wide layers and decoupled subdomain services.

Barebone services

A few architectures are completely segmented into subdomains:

• Distributed Services or in-process Modules rely on mutual orchestration. They come in several kinds:
  - Service-Based Architecture tends to employ single instances of services which cover entire subdomains. It is used for multi-team server-side projects with no special performance considerations.
  - Modulith (Modular Monolith) runs subdomain-sized components in a single process, sacrificing fault tolerance for consistency and operational costs. This architecture fits smaller Internet businesses.
  - Microservices with highly scalable sub-subdomain components implement high load and high budget systems with well-established domain knowledge but frequently changing business needs.
  - Actors are asynchronous objects used for real-time tasks that range from embedded telephony to instant messengers to financial systems. Consider them if you benefit from modeling every user of your system as a lightweight independently acting entity.
• Three-Layered Services subdivide each service into the use cases, domain logic, and persistence layers, allowing for further specialization of staff and technologies.
• Pipeline is a choreographed system where each component implements a single stage of data or event processing:
  - Pipes and Filters is a local and usually linear Pipeline that processes a data stream. It is the architecture of choice for systems with customizable workflows and polymorphic algorithms such as video capture or replay.
  - Choreographed Event-Driven Architecture runs multiple branched Pipelines, each implementing a single use case, over a shared set of services. It is an easily extendable alternative to Microservices for domains with a few highly loaded yet simple scenarios.
  - Data Mesh collects, transforms, and processes analytical data from a system of services.
• Two-Layered Services split each component of a Pipeline (usually a Choreographed Event-Driven Architecture) into domain logic and persistence layers, emphasizing the use of databases private to their services. Noticeably, the use case logic is represented as the connections between the services.

Services with extensions

Services become simpler when common aspects are extracted to a dedicated layer:

• Services with a Middleware rely on an external transport and deployment layer which is usually a framework available off-the-shelf:
  - Service Mesh is a distributed Middleware for highly scalable systems.
  - Message Bus interconnects services that use different communication technologies by translating between their protocols. It is useful in integration of legacy systems.
  - Event Mediator drives communication in Event-Driven Architectures.
  - Enterprise Service Bus is an orchestrating Middleware that unites several historically separate subsystems into an Enterprise Service-Oriented Architecture.
• Services with a Shared Repository share a data storage or exchange layer and are eligible to implement data-centric domains:
  - Shared Database simplifies architectural design and data synchronization (see Service-Based Architecture).
  - Shared File System is among the simplest methods of organizing Pipelines for processing large volumes of data records.
  - Shared Memory is the fastest method of data exchange especially suitable for low latency software.
  - Data Grid is a highly scalable, distributed in-memory datastore of Space-Based Architecture.
• Services with Polyglot Persistence employ several databases, usually to improve performance by using each database in the role it is optimized for.
• Services with a Gateway rely on a shared Proxy layer to handle communication with clients. Third-party Proxies reliably cover security and networking concerns with very little effort from the programmers’ side.
• In Orchestrated Services it is the use cases which are extracted into a system-wide layer. Such subdivision of business logic saves the day when there are many complex system-wide scenarios while the business rules are specific to particular subdomains.
• Services with an API Gateway implement public-API-related tasks — both protocol support and basic orchestration — in a single component which calls underlying services containing the domain logic. This is a simplified architecture for ordinary server-side systems.
• Services with Backends for Frontends have a layer of client-specific components that encapsulate clients’ protocols and/or scenarios and are useful when a system serves drastically different kinds of clients.

Hierarchies of services

Services are building blocks for a couple of hierarchical architectures used in huge projects:

• Cell-Based Architecture is a system of clusters of (often co-deployed) services called Cells. Recursive decomposition lowers the top-level system complexity and decouples the subdomains by making their interdependencies explicit.
• Hierarchical Middleware interconnects several subsystems of services which belong to different organizations or physical networks.

Partially merged services

There are systems in-between Services and Monolith or Layers:

• In Modulith with shared code the business logic is split into subdomains but still relies on a shared codebase. It is a transitional architecture often seen in growing projects that explore subdomain boundaries.
• In Sandwich only the domain logic layer, which is usually the largest part of the codebase, is segmented into subdomains. This is the most natural subdivision for many real-world systems and which inspires multiple architectures:
  - Service-Based Architecture — the pragmatic approach to server-side development — often uses a Shared Database and an API Gateway.
  - Space-Based Architecture provides unparalleled elasticity and scalability for data-centric domains with its replicated cache called Data Grid.
  - Blackboard Architecture schedules specialized algorithms to solve ill-structured problems.
  - Nanoservices are independently scalable functions that run in a cloud and share an (API) Gateway and a database.

Fragmented patterns

Finally, some architectures are subdivided into both layers of abstraction and subdomains, resulting in topologies containing many small components. This happens when interacting parts of a system vary in their qualities and technologies and thus should stay separate, ordinary decomposition results in components too large for comfortable development, or both.

Layers of services

A few topologies are made of layers, each of which is subdivided into services:

• In Services with Polyglot Persistence there are several specialized databases with shared access. This topology may emerge from performance optimization of Services with a Shared Repository.
• Services with Backends for Frontends employ a dedicated Proxy, Orchestrator, or API Gateway for each kind of client. This makes sense when the system’s clients have very little in common.
• Service-Oriented Architecture features fragmented application, domain, and utility layers, with each component of a higher level calling multiple components from a layer below it. It enables code reuse, for better or worse, and has reasonably small services even in huge projects but suffers from slow development caused by extensive interdependencies between teams.

Layered services

More often than not, services are layered internally:

• Orchestrated Three-Layered Services distinguish between the application (use cases), domain (business rules), and persistence (database) layers.
• Choreographed Two-Layered Services contain only the domain and persistence layers because the application logic resides in the graph of connections between the services.

Hierarchies

Finally, there are hierarchical topologies with recursive partitioning:

• Top-Down Hierarchy is arguably the best way to implement a system that involves many kinds of somewhat related entities. It emerges in domains as diverse as compilers, industrial automation, graphical user interfaces, and online marketplaces.
• Hierarchical Middleware interconnects subsystems that differ in their communication protocols.
• Cell-Based Architecture splits every large subdomain service into a group of subservices encapsulated with a Cell Gateway. This keeps individual services small without spreading hundreds of them into the system level.

Common motifs

Every area of the topologies map highlights certain design principles:

• Small and simple systems may stay cohesive as Monoliths or Shards.
• Medium-sized software benefits from functional partitioning [FSA] into Layers.
• Long-lived projects become stabilized by extracting any volatile code into expendable modules. Different applications of this principle yield Plugins, Hexagonal Architecture, and Microkernel.
• Large software is decomposed into subdomains owned by dedicated teams. See Services and Pipeline.
• Huge systems require recursive decomposition as found in Service-Oriented Architecture and Hierarchy.

Other motifs are harder to notice as they apply to both scaled monolithic or layered systems and those subdivided into services:

• There is often a managing layer that makes use of underlying components:
  - A Proxy is an interface that receives and pre-processes client input, then forwards the resulting request to whatever is behind it.
  - An Orchestrator is an application that implements complex use cases which turn a single event or client request into a chain of calls to the lower layer.
  - Backends for Frontends segment a managing layer into client-specific services.
• A platform layer provides some functionality to other system components:
  - A Middleware deploys and interconnects Services or Replicas.
  - A Shared Repository stores the system’s data, offering consistency and persistence.
  - Polyglot Persistence subdivides a Shared Repository layer.
• Sandwich wraps Services or Replicas with both managing and platform layers.
• A Mesh interconnects any components that use it.

Obviously, metapatterns emerge as archetypes shared among system topologies.

Summary

There are many system topologies with various degrees of segregation into layers and subdomains. No single architecture is a silver bullet, each topology has its use depending on the circumstances. The following chapters of this book explore archetypes shared among topologies which are called metapatterns.

Editor: Lars Noodén

The Map of System Topologies was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Application of the isolation principle behind Hexagonal Architecture to a distributed subsystem results in a Cell (according to WSO2, not Amazon) — an encapsulated cluster of Services which implements a subdomain and is usually deployed as a single unit.

In the simplest implementation a Cell’s contents are hidden from the Cell’s clients by a Cell Gateway which acts as an Open Host Service [DDD], allowing for anything inside the Cell to be changed at will with no effect on the outside world.

Better developed Cells employ Adapters [GoF, DDS] and Plugins [FSA, PEAA] for outgoing requests to build an Anticorruption Layer [DDD] that protects the Cell’s contents from changes in its environment.

This dichotomy is similar to that between Separated Presentation (indirection between the system and its users or clients) and Ports and Adapters (full isolation of the business logic from its environment).

In practice there are three kinds of outgoing traffic: responses to incoming client requests, pub/sub notifications, and requests to external services. In a Cell, responses are sure to pass through or be generated by the Cell Gateway. Indeed, a response usually reuses the request’s transport, therefore if a request arrives at the Gateway, the corresponding response should also start there. Notifications are harder to pinpoint: on one hand, they are a part of the Cell’s API which the Gateway takes care of. However, that means that the Cell’s internals must be aware of the Gateway’s existence to use it for notifications, thus creating a dependency that violates the normal order for a layered system. Finally, outgoing requests bypass the Cell Gateway whose role is limited to the Cell’s API.

Cells facilitate recursive decomposition by subdomain. They are the building blocks for the following patterns:

• Cell-Based Architecture which is hierarchical Services.
• Domain-Oriented Microservice Architecture which is a SOA boosted by advanced Cell features.

Basic Cell, Cluster

A Cell (WSO2 definition) or Cluster [DEDS] may naturally emerge when a subdomain service becomes too large for comfortable development, which usually means that at least its domain layer (already limited to a single subdomain) is to be subdivided into subsubdomain components. If other layers remain intact, this leads to a Sandwich, otherwise the result is a subsystem of Services or a Pipeline.

As it is undesirable to let the new components appear at the top system level because that would increase the system’s integration complexity:

• The newly created subservices are hidden behind a Cell Gateway (which coincides with the topmost layer in case of a Sandwich) so that everything outside of the Cell remains ignorant of what is within it, and the Cell contents will thus retain the freedom to change.
• Everything within a Cell is deployed and scaled together to avoid the overhead of versioning and keep the number of system components small (the entire Cell is operated as a single service).
• As a rule [DEDS], the communication inside a Cell remains synchronous, allowing for complex orchestrated use cases that involve many tightly coupled Cell components. Contrariwise, there is usually asynchronous messaging between loosely coupled Cells, which make a choreographed system.

As a matter of fact, forming a Cell tackles the complexity of an overgrown service without leaking any implementation details to its clients or committing to irrevocable architectural decisions. We will be able to make gradual changes to our Cell’s code and structure as our clients see only the Published Language [DDD] of our Cell’s API via its Cell Gateway, which thus becomes an Open Host Service [DDD].

Another way a Cell can arise is when architects have overcommitted themselves to Microservices, gradually introducing hundreds of them and turning their project into a Microservice Hell. Now they need to group their services to:

• Have a clear high-level picture of what is going on in the system.
• Cut accidental dependencies between their services and the teams behind them.
• Improve latency by co-locating the services that interact intensely.

Basic Cells have a downside: even though we have protected our clients from changes in our implementation, our code is still vulnerable to changes in any external services which it uses. To fix that, we will need to add a layer of indirection for outgoing communication as well:

Full-Featured Cell, Domain

Regardless of how a Cell emerges, the isolation of its contents can be improved through the addition of Adapters [GoF, DDS] for any external services used by the Cell. Please note that, unlike in Ports and Adapters, there is no Adapter for a Cell’s database(s) as it is inside the Cell’s perimeter.

Another improvement, popularized by Uber’s Domains, is the use of Ambassador [DDS] Plugins [FSA, PEAA] which run other services’ business logic inside your Cell. That both avoids slow intercell calls and boosts the system’s fault tolerance as each Cell can now operate independently.

In Uber the service responsible for a driver’s status accepts Plugins from other services, such as safety checks or compliance, which can block the driver from appearing in the system and responding to ride requests.

The Adapters and Plugins make the Cell’s Anticorruption Layer [DDD], completing the Cell’s boundary that allows for the Cell’s logic to be implemented and tested in isolation from the external environment.

Summary

Cell applies the principles of Hexagonal Architecture to a distributed subsystem. It allows for recursive decomposition of software into subsubdomain components while preserving the high-level system complexity at a moderate level.

References

DDD — Domain-Driven Design: Tackling Complexity in the Heart of Software. Eric Evans. Addison-Wesley (2003).

DDS — Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services. Brendan Burns. O’Reilly Media, Inc. (2018).

DEDS — Designing Event-Driven Systems: Concepts and Patterns for Streaming Services with Apache Kafka. Ben Stopford. O’Reilly Media, Inc. (2018).

FSA — Fundamentals of Software Architecture: An Engineering Approach. Mark Richards and Neal Ford. O’Reilly Media, Inc. (2020).

GoF — Design Patterns: Elements of Reusable Object-Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Addison-Wesley (1994).

PEAA — Patterns of Enterprise Application Architecture. Martin Fowler. Addison-Wesley Professional (2002).

This is an early version of a section from my book Architectural Metapatterns. It will appear in the upcoming version 1.2 which is to be released in about a month. Meanwhile, feel free to check the version 1.1 which is available online and on GitHub.

Editor: Lars Noodén

Cell was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is an early version of a chapter from my book Architectural Metapatterns. It will appear in the upcoming version 1.2 of the book which is to be released in about a month. Meanwhile, feel free to check the version 1.1 which is available online and on GitHub.

Follow the line of least resistance. Divide where it is loosely coupled.

Examples:

• Blackboard System [POSA1, POSA4],
• Space-Based Architecture (SBA) [SAP, FSA],
• Service-Based Architecture (SBA) [SAP],
• Command Query Responsibility Segregation (CQRS),
• (inexact) Replicated Load-Balanced Services [DDS] / Lambdas.

Structure: A layer of domain-level services between shared integration and data layers.

Type: Main, implementation.

References: None I know of.

A Sandwich is a (sub)system in transition between Layers and Services. It emerges when a layered component outgrows its architecture and its middle (domain [DDD]) layer — which tends to be both the largest and least cohesive — is divided into subdomains while the application and data layers remain intact. Another, less common, origin is a (sub)system of (Micro)Services which becomes so tightly coupled that it needs to be partially merged.

A Sandwich includes the following components:

• A shared integration layer which receives client requests and dispatches them to the underlying domain-level services. Though this layer may either implement use cases as an Orchestrator or just forward each client action to a matching service as a Proxy, it remains the component that ties the entire system together.
• Domain-level services (if distributed) or modules (otherwise) that implement the bulk of the system’s business logic and thus contain most of the system’s code.
• A shared data layer which the upper layer’s services operate on. It may be a database (provide persistence) or an in-memory application state.

Sandwiches often occur naturally without being recognized as a distinct architecture. In fact, I had to make up a name for this system topology.

Performance

As domain-level services rarely interact among themselves, the performance of a Sandwich is similar to that of Layers with the same kind of deployment (components of a Sandwich may or may not be colocated).

Dependencies

The Sandwich’s integration layer depends on every service inside the Sandwich. The services themselves depend on the data layer.

Having two shared layers provides three options for invoking the domain components:

• The most common approach is orchestration by the integration layer.
• Data-centric domains may rely on data change notifications.
• Choreography via publish/subscribe is rare because it is inferior to the other two options:
• - It does not help to decouple the subdomain services which remain bound together by the shared layers.
• - Publish/subscribe requires additional libraries and setup, while the datastore, which often supports notifications, is already in place.
• - Furthermore, orchestration allows for much better control over use case logic and error handling than choreography.

Applicability

Sandwich fits:

• Medium-sized projects with complex domain logic. The subdivision of the domain layer keeps the code complexity under control and supports development by multiple teams with little increase of operational burden.
• Rapid development of ordinary systems. If you don’t face any challenging forces, you should keep your architecture simple and stupid but still flexible — which is the pragmatic Sandwich. You will be able to evolve it in the future if needed.
• Data-centric domains. This architecture allows all the services to work on the same dataset, each reading and writing the parts that are involved in its business logic.

Sandwich does not help:

• Projects with a large number of use cases. As the integration layer remains monolithic, it still can grow out of control, requiring the system to transform into Layered Services.
• Huge systems. Both the integration and data layers are cumbersome in that case.
• Demanding forces. The Sandwich architecture is a jack of all trades, master of none. In general, it is an average backend, and is neither highly elastic, flexible, nor low latency.

Relations

Sandwich:

• Is a system in transition between Layers and Services.
• Is Layers with a middle layer split into services or Services sandwiched between layers.
• May implement a Monolith or Service.
• Often provides the internals of a Cell.
• Includes a Shared Repository and an Orchestrator and/or Proxy.

A Cell encapsulates several services so that they can be treated as a single entity with the goal of reducing the number of top-level system components. Typically, interdependent and closely communicating services are clustered into a single Cell, predisposing the Cell’s internals for further merging to reduce the communication overhead and the amount of boilerplate code. Such a scenario often results in a Sandwich trapped inside a Cell.

Examples

Though most real-world Sandwiches stay beneath the radar as non-standard architectures, there are two well-documented and highly specialized occurrences of this topology in data-centric domains and a few less stringent generic cases:

Blackboard System

Some domains are complex and ill-structured: there is only a vague understanding of how the inputs relate to outputs, therefore you cannot write a single algorithm to solve it. If you are lucky to have a huge labeled dataset, you can attempt training a neural network. If there are not so many examples, you are in trouble.

Blackboard Systems [POSA1, POSA4] were invented half a century ago to tackle non-deterministic problems: speech or image recognition, X-ray crystallography of proteins, or even tracking enemy submarines or stealth aircraft. In these cases inputs are noisy and scarce and outputs can vary indefinitely, therefore one must go through trial and error proposing, refining, and comparing many possible solutions to arrive at something plausible.

The system consists of:

• A blackboard — a shared data store that contains all the current knowledge about the problem, namely inputs and hypotheses. It is subdivided into abstraction levels which range from the original inputs through multiple intermediate representations to the output data structure. Each level usually contains multiple solution attempts.
• Knowledge sources — independent, specialized components that process data from a lower level to create a higher-level hypothesis. For example, in voice recognition, a knowledge source may read a sound wave and write a letter which that wave encodes. Another knowledge source may read letters and output English words, while another one tries to find French words. And the final one collects words into sentences.
• A control — a scheduler that assigns processor time to knowledge sources. It balances the quality and speed of the solution attempts based on the current progress and remaining time.

This architecture makes best use of every system layer:

• The control is required to prune the exponential growth of possible solutions because there are not enough system resources to check all of them.
• The independent knowledge sources are easy to add or remove, allowing the developers to try various algorithms with no changes to other components.
• The blackboard enables the cooperation of knowledge sources, each of which is limited to a small part of the overall solution.

Space-Based Architecture (SBA)

Space-Based Architecture (SBA) [SAP, FSA] is an extremely elastic alternative to Microservices which works for data-centric domains. Each processing unit — a domain-level service — is co-located with an in-memory replica of the entire system’s data, which makes both data access and creation of new instances of processing units blazingly fast. As is common for Sandwiches, processing units can be orchestrated by the processing grid or they can subscribe to changes in the shared data grid, this architecture being flexible enough to allow for choosing a communication paradigm on per request basis.

Aside from processing units, which contain the main business logic, SBA involves:

• A messaging grid which is a Proxy (combination of Gateway, Dispatcher, and Load Balancer) that receives, preprocesses, and persists client requests. Simple requests are forwarded to the least loaded processing unit (service with domain logic) while anything complicated goes to the processing grid.
• A processing grid is an optional Orchestrator which manages multi-step workflows for complicated requests that involve branching and error handling.
• A data grid is a distributed in-memory database. It is built of caching Mesh nodes which are co-located with instances of processing units, making database access extremely fast. However, the speed and scalability is paid for with stability — any data in memory is prone to disappearing. Therefore the data grid backs up all the changes to a slower persistent database.
• A deployment manager is a Middleware that creates and destroys instances of processing units (which are paired to the nodes of the data grid), just like Service Mesh does for Microservices (which are paired to Sidecars [DDS]). However, in contrast to Service Mesh, it does not provide a messaging infrastructure because processing units communicate by sharing data via the data grid, not by sending messages.

As SBA runs every component in a Mesh, it avoids the fault tolerance and database performance drawbacks inherent to Sandwich, trading them for possibility of write conflicts when multiple clients cause changes to the same piece of data simultaneously.

Service-Based Architecture (SBA)

Service-Based Architecture (SBA) [FSA] is the most pragmatic and loosely defined of topologies based on Services (hence the name). In its most basic shape, SBA’s subdomain services are integrated by a User Interface layer, usually a Frontend, and there is a single Shared Database. However, as there are no rules for SBA, multiple databases or finer-grained GUIs may be used for programmers’ convenience, disintegrating the Sandwich architecture for the sake of less coupled Layered Services.

Command Query Responsibility Segregation (CQRS)

Command Query Responsibility Segregation (CQRS) is a principle which calls for separation of components that process commands (requests that change the system’s data) and queries (requests that analyze the data). The subdivision necessarily happens at the domain (model) level, resulting in separate Write Model (Command Model) and Read Model (Query Model, Thin Read Layer).

In the simplest case the data layer is kept monolithic, as shown in the diagram above. That helps decouple the logic-heavy object-oriented code which maintains data consistency and business constraints during editing from the search and aggregation code that needs direct database access to run complex SQL queries. If that is not enough, it is possible to trade complexity for performance by employing specialized databases: OLTP for use with the Write Model and OLAP for the Read Model, as described in Layered Services:

(inexact) Replicated Load-Balanced Services, Lambdas

Replicating a system’s domain tier along the sharding axis also results in a Sandwich-like topology, albeit with altered properties: while the original Sandwich’s subdivision of the codebase along the subdomain axis allows for multiteam development and easy integration of new functionality, replication along the sharding axis only makes it simple to add or remove instances of the middle tier as the system load changes.

Replicated Load-Balanced Services [DDS] is the general name for running multiple instances of a stateless service that share a database and run under a Load Balancer. Lambdas is a synonym for a similar setup from cloud computing providers.

Evolutions

The components of a Sandwich provide plenty of ways to alter the system:

Primary evolutions

Some evolutions involve the system’s domain logic or its topology:

• The domain-level services are independent enough to be easily added or removed.

• In most cases they share technologies, allowing for splitting or merging of the services.

• If the services are found to be strongly coupled, they can be merged into a monolithic layer, likely to be subdivided in a better way later on.

• Alternatively, the subdomains can be further decoupled.

Evolutions of the data layer

If the data layer becomes a performance bottleneck, it can be split as a Shared Repository:

• Shard the database if its records are mutually independent or replicate it if it is the read traffic which overloads the system.
• Apply Space-Based Architecture if elasticity is more important than consistency.
• Divide the data into databases, private to domain-level services, transforming the system into Orchestrated Services.
• Deploy specialized databases (Polyglot Persistence).

Evolutions of the application layer

If the integration layer contains use cases and becomes cumbersome, it should be subdivided following the evolutions of Orchestrator:

• Into Services if the use cases cluster around subdomains.
• Into Backends for Frontends if the system serves several kinds of clients.
• Into Layers if some use cases are simple while others are complicated.
• Into a Hierarchy if the use cases include both generic and specialized logic.

Summary

Sandwich is a pragmatic architecture midway between Layers and Services. It combines simplicity and flexibility, avoiding unnecessary effort for the present while retaining many paths to evolve in the future.

References

DDD — Domain-Driven Design: Tackling Complexity in the Heart of Software. Eric Evans. Addison-Wesley (2003).

DDS — Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services. Brendan Burns. O’Reilly Media, Inc. (2018).

FSA — Fundamentals of Software Architecture: An Engineering Approach. Mark Richards and Neal Ford. O’Reilly Media, Inc. (2020).

POSA1 — Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad and Michael Stal. John Wiley & Sons, Inc. (1996).

POSA4 — Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing. Frank Buschmann, Kevlin Henney, Douglas C. Schmidt. John Wiley & Sons, Ltd. (2007).

SAP — Software Architecture Patterns. Mark Richards. O’Reilly Media, Inc. (2015). (All of the architectures referenced here are in [FSA] as well, but [SAP] is free)

Editor: Lars Noodén

Sandwich Architecture was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

Patterns of Patterns, and why we need them:

• The misery of having thousands of patterns.
• Local and distributed architectures are not dissimilar.
• Structure determines function.
• There are only so many elementary geometries.
• Which means that hundreds of patterns condense into several metapatterns.

Basic Architectures, the building blocks for complex systems:

• Monolith — a cohesive codebase.
• Shards — multiple instances of a (sub)system.
• Layers — subdivision by the level of abstractness.
• Services — components, dedicated to subdomains.
• Pipeline — a chain of data processing steps.

… and common variants of each of the architectures.

Architectural Extensions. Making use of specialized components:

• Middleware — communication and deployment.
• Shared Repository — persistence and synchronization.
• Proxy — protocols, routing, and security.
• Orchestrator — integration and use cases.
• Combined Component — multiple aspects.

Fragmented Architectures. Patterns with smaller components:

• Layered Services — divide into services, then into layers.
• Polyglot Persistence — employ multiple databases.
• Backends for Frontends (BFF) — dedicate a service to each kind of client.
• Service-Oriented Architecture (SOA) — divide into layers, then into services.
• Hierarchy — recursive subdivision.

Implementation Patterns. The high-level design of system components:

• Plugins customize the component’s behavior.
• Hexagonal Architecture isolates the business logic from external dependencies.
• Microkernel mediates between resource providers and resource consumers.
• Mesh maintains a decentralized system.

I hope that the presentations will help you quickly find out if you are interested in the book.

Merry Christmas!

Here is a brief presentation of the main ideas from my book Architectural Metapatterns:

• The misery of having thousands of patterns.
• Local and distributed architectures are not dissimilar.
• Structure determines function.
• There are only so many elementary geometries.
• Which means that hundreds of patterns condense into several metapatterns.

The website shows how patterns of software architecture work together and relate to each other. It’s lightweight, blazingly fast and modile-friendly. There is a native dark theme:

Each page is dedicated to a basic principle of software architecture or to a cluster of related architectural patterns. It’s an updated version of everything I have published on Medium.

Enjoy!

The latest version (1.1) of my book Architectural Metapatterns is now available online, hosted by GitHub wiki. Here is the index of patterns it describes.

The wiki was generated with odt2wiki — a small utility which converts ODT (LibreOffice/OpenOffice text documents) to the GitHub wiki format, splitting the document into multiple web pages and matching images from the document to files in your local folder.

Next I am going to try transforming the book into a static web site, likely through Hugo Book or Sphinx Book Theme. Any advice is welcome.

While it is convenient to write a book in Google Docs, transforming it into a high-quality eBook is complicated. Please find below the steps which one should take to make a pair of PDB and EPUB files from a Google Docs document using free software.

I have Ubuntu 22.04 / MATE 1.26, LibreOffice 7.3.7.2, and Calibre 5.37.

Why Google Docs

I used Google Docs for writing a compendium which contained hundreds of pages, hundreds of diagrams, and thousands of cross-links.

Benefits

• Online collaboration
• Decent UX
• Decent stability (few bugs, no data corruption)
• Performance (Google Docs seems to be faster than LibreOffice Writer)
• Instant backup
• You probably don’t need to learn it

Drawbacks

• Supports only basic editing
• Exporting is basic as well
• No integration with version control systems
• Unavailable offline

The troubles you may encounter

• Google Docs has a hard time saving the table of contents into a PDF (as an outline) or EPUB file. Older versions did not generate it at all, whilst the newer ones may be buggy and provide next to no control over the structure of the table of contents.
• The resulting EPUB is not optimized. It may take too long to open and section breaks may be at the wrong granularity level.

Use specialized software

It makes sense to rely on specialized tools:

• Google Docs for editing and collaboration
• Calibre for conversion to EPUB
• LibreOffice for conversion to PDF

Exporting from Google Docs to LibreOffice Writer

Even though Google Docs and LibreOffice Writer are about the same thing, they differ in many details. I suppose that you have perfected your book in Google Docs and now want it to look the same in the output PDF file.

So you just go to File -> Download -> OpenDocument Format (.odt) in your Google Docs, wait for the download to complete, open the downloaded document with LibreOffice and compare it to the original. I looked at the lengths of the documents - they should match. If they don't, you should probably check the length of every chapter to find the differences. A few hints are below:

UPDATE: Google Docs became too slow to generate an .ODT from my book. It fails silently (the file is never downloaded). I have to download it as a .DOCX, open the DOSX with LibreOffice and save it as an .ODT file.

Fonts

The Google Docs set of fonts differs from that in OpenOffice Writer. I used Oswald in the explanation sections of my book only to find out that LibreOffice Writer silently replaces it with a default font.

Therefore, please check all kinds of text styles which you use throughout your book. If anything looks wrong, you may have to download a corresponding font from Google and install it on your computer.

Document structure

Google Docs uses header text style for chapters and sections. With LibreOffice Writer styles and structure are separate.

You will need to:

• open the “Styles and Formatting” right-side panel and right-click and Modify... the header styles there or
• right-click on each kind of header in your document and choose Paragraph -> Edit Style... to set up the outline levels. The outline levels are set up in the Outline & List paragraph style tab.

For example, in my book there are:

1. Title style for book parts — it gets outline level 1
2. Heading 1 style for chapters — outline level 2
3. Heading 2 style for groups of sections — outline level 3
4. Heading 2 style for individual sections — outline level 4

Please be aware that now your book’s title or blank lines from the title page may appear as stray chapters in the table of contents, unless you change their styles to default and set up their font sizes manually.

Orphaned lines

Google Docs prevents single lines of text from appearing at the top or bottom of the page. LibreOffice Writer has two controls for that: Orphan control and Widow control. Both are in the Text Flow tab of the paragraph style dialog.

You have to enable both of them for the default paragraph style. Please note that they are already enabled for headings.

There is also a subtle difference in the logic of the feature: while Google Docs keeps a header, diagram, and the following caption line together, LibreOffice Writer does not consider them to be a single paragraph, thus you may see a caption separated from its diagrams or a section header together with a diagram separated from the section’s text. Fixing that will likely require manual changes which may be as simple as inserting a blank line before every diagram with a caption.

Tables

Google Docs seems to generate tables with no padding. While the tables look good in Google Docs, in LibreOffice Writer the spacing between cells is smaller than the spacing between lines of text inside a cell.

Thus you may need to increase padding in the Table Properties -> Borders dialog for each table in your document. There seems to be no easy way to select all the tables - you'll have to edit each of them manually.

Transparency

I used transparency to reduce the contrast of the background image on the title page of my book.

LibreOffice Writer does not support transparency for images, only for page areas. I had to delete the cover image and re-insert it through Page Style -> Area -> Image to make it semi-transparent via Page Style -> Transparency.

Bullets and fonts

If you use multiple fonts in a list, the list’s bullets will differ in size. You’ll need to left-click a bullet (this selects all the bullets in the list) and choose a font which will apply to all the bullets.

Known bugs

There are several LibreOffice Writer bugs (as of 7.3.7.2) that cause inconveniences:

• Recovery of a document after a crash may corrupt suggestions — additions become deletions. This is a point against offline collaboration via ODT files.
• Autosave (recovery backup) cannot be disabled via Options -> Load/Save -> General -> Save AutoRecovery information. This is really annoying for large documents as the saving takes half a minute and happens every 10 minutes.
• Paragraph Style -> Text Flow -> Keep with next paragraph setting is not applied when a document is loaded. Opening the style dialog for a header and just pressing OK will reformat the document and may change its number of pages and the PDF output.

Exporting to a PDF

This is straightforward:

• Run File -> Export As -> Export as PDF... in LibreOffice Writer.
• Be sure that the Archive (PDF/A, ISO 19005) box is checked.
• The Export outlines checkbox is responsible for creation of the table of contents.

Now you have your PDF with a nice table of contents!

Making a EPUB

This part is complicated.

You will probably want to make a copy of your document as the steps below involve destructive modifications.

Get rid of the title page

The EPUB includes the cover as a stand-alone image. Therefore you should delete the cover page from your document to avoid its being duplicated. Which is not that easy because the title page’s properties differ from those of other pages, therefore merely deleting the cover page’s text and image does not work — the second page becomes the new title page.

I found the following workaround:

• Delete the contents of your title page. Your second page will become your title page.
• Select Format -> Title Page... -> Make Title Pages -> Insert new title pages. Press OK - that should insert a blank default-style title page in front of the document
• Now delete the newly inserted blank lines to pull the text from your second page into the first page.
• Save the updated document.

Generate the cover image

Now you need to create the cover (printout of your title page) for your EPUB. There are two ways:

• KISS: Make a screenshot of your title page in Google Docs or LibreOffice Writer.
• The knightly path: Extract it from the PDF file generated in the previous section. Assuming you are on Linux, run pdftoppm -singlefile -png YourBook.pdf > Cover.png

Create the EPUB

You will need Calibre. Install it.

Open your ODT file without the title page with Calibre (that should be possible through right-clicking the file and choosing Open with other application).

Right-click on the newly created book in Calibre’s library (its main page) and select Edit metadata -> Edit metadata individually.

• Set the book’s cover from the image generated in the previous step.
• Fill in the title and author(s).
• You can add tags, but I don’t know if they appear in the published book, or are internal to Calibre.
• Apply the changes.

Right-click on your book. Convert books -> Convert individually.

• Choose ODT as input and EPUB as output format.

Fonts tab of the Look and Feel dialog:

• Check Embed all fonts
• Check Subset all embedded fonts

There is some magic under the Structure detection dialog:

• Detect chapters works with //*[name()='h1' or name()='h2' or name()='h3' or name()='h4'] - This probably is related to the table of contents. Calibre's table of contents is limited to 3 levels, however.
• Insert page breaks before should detect every kind of section if we want every section to appear on a new page: //*[name()='h1' or name()='h2' or name()='h3' or name()='h4'].

The Table of Contents dialog also needs your attention:

• Change the Number of links to add to a big number like 500.
• The levels are required for a multi-level (hierarchical) table of contents:
• Set Level 1 TOC to //*[name()='h1']
• Set Level 2 TOC to //*[name()='h2']
• Set Level 3 TOC to //*[name()='h3']
• Check Manually fine-tune the ToC after conversion.

Click OK and wait for a couple of minutes.

Enjoy the preview of your table of contents. You can edit it manually or delete and regenerate it with the buttons on the right side of the dialog.

Alternatively, you can delete the generated table of contents by pressing Ctrl+A and del and create a new full-depth table of contents by using the Create table of contents from all headers button (and choosing Include duplicates if a pop-up appears). This allows for making a 4-level table of contents and also adds introductory sections.

If you work on the table of contents for a couple of minutes, there will appear a pop-up warning about a ToC creation timeout. It is safe to ignore.

Right-Click on your book. Choose Open containing folder. Enjoy the EPUB you've created!

Issues with Calibre’s EPUB

There are a couple of troubles with the Calibre’s output:

It uses <class="calibre"> in a non-standard place which results in errors from EPUB validation tools. If your publisher insists on fixing the errors (PublishDrive does), you should:

• Install Sigil.
• Open the EPUB with Sigil.
• Find class="calibre"> and replace it with > throughout the EPUB contents (All HTML Files).

Lists are not well-aligned. Fixing that requires knowledge of CSS.

Publish the book

I tried Leanpub (PDF and EPUB) and PublishDrive (EPUB only).

PublishDrive is stringent on errors. You will need to fix the EPUB created by Calibre (see above).

Leanpub accepts everything, but it has a couple of peculiarities:

Generating the table of contents for Leanpub

Leanpub expects you to generate the table of contents of your book as a HTML list. You will need to do the following:

• Open your EPUB (3 ToC levels) or PDF (4 ToC levels but it may take forever to open) file with Calibre’s E-book viewer.
• Right-click on the table of contents in the viewer and select Copy Table of Contents to clipboard.
• Paste the table of contents into your favorite plain text editor and save it as a TXT file. You may also edit the contents if needed.
• Download my converter (a tiny Python script) and run it (the following works on Linux, for Windows you may have to prepend `python`): ./toc_to_html.py toc.txt toc.html
• Open the generated HTML file with a plain text editor and copy-paste its contents into your book’s Leanpub page.

Generating a sample chapter

You will probably want Leanpub to offer prospective readers to download a sample chapter from your book. However, that requires you to prepare the corresponding PDF and EPUB files:

• Clone the book in Google Docs
• Edit the cover
• Delete everything except the table of contents, the chapter you will use for promotion and, probably, a few appendixes.
• Unlink any cross-references to the deleted chapters throughout the remaining text, including the table of contents.
• Download the sample as ODT.
• Repeat all the steps which you did for your book:
• Fix the ODT with LibreOffice Writer.
• Convert it to PDF.
• Convert it to EPUB with Calibre.

That’s it. Enjoy your book.

Please feel free to contact me if you have any improvements for this instruction.

This is a bugfix release made possible by Lars Noodén who volunteered to edit the book. Now its English and styling are better.

What’s inside?

The book is a taxonomy and compendium of architectural patterns with hundreds of NoUML diagrams. Available as PDF and EPUB.

How much does it cost?

It’s free, distributed under the CC-BY license. You can download the book from GitHub or Leanpub.

Are there any testimonials?

Yes, including one from Mark Richards. Please see the book’s Leanpub page.

How can I help?

1. Tell your friends about the book.
2. Propose corrections, improvements or patterns which I missed.
3. Become a co-author — the book needs one or two case studies.

The book is ready. Now it contains everything I wanted it to have and much more:

• An intuitive classification of architectural patterns.
• A universal pattern language that interconnects hundreds of patterns.
• Lots of diagrams to skim through — they make a parallel narrative.
• Basic principles of software architecture.
• Comparison of approaches to select aspects of software design.

It collected praise from experts, including Mark Richards, whose books I relied on. I asked for critical reviews to improve my book — and received testimonials for publishing it instead.

Looking back, I don’t believe that I have written it. It is too complex and daring, solving the long-standing issue of pattern classification and unifying software and system architecture. God installed the idea and led me through writing it down. Now it’s over. I am yet another unemployed programmer from Ukraine.

Something new lies ahead. I have nothing to aspire after in software engineering anymore. Let’s wait and see.