Assemblage overview: Part 3 - What's a service architecture?

application architecture   architecting   dark energy and dark matter   assemblage   microservice architecture   service architecture  

---

---

In previous articles, I described the first two steps of the Assemblage architecture design process. The first step identifies the system operations, which model externally invoked requests. The second step of the process designs the subdomains that implement those system operations. The third step of the design process defines the service architecture. In a later article, I’ll describe the service design process in more detail. In this article, I’ll provide an overview of the service architecture.

What’s the service architecture?

The service architecture consists of one or more services. The services are a grouping/partitioning of the application’s subdomains that were defined in step 2. Each service consists of one or more subdomains. Each subdomain is in one and only one service. If the service architecture consists of one service, it’s a monolith and if there’s more than one, it’s a microservice architecture.

Defining service architecture is most critical part of designing an architecture. If you do a good job, you’ll have a good architecture that will, for example, accelerate software delivery. Conversely, if you do a bad job, you risk slowing down software delivery. In the worst case, you’ll create a distributed monolith, which is an anti-pattern architecture that combines the worst aspects of monoliths and microservices.

The service architecture can be (mostly) defined in a technology neutral way. The focus is on correctly defining the service boundaries and their collaborations. Even the communication between services can be defined in a technology neutral way. You can (and should), for example, model messaging in terms of messaging channels rather than instantly picking a message broker.

… versus the technical architecture?

Once you’ve defined the service architecture, you can then define the technical architecture. The technical architecture consists of a set of specific technology choices. In fact, most of the decisions that you must make consist of applying the Microservice pattern language including deployment patterns, communication patterns, and observability patterns.

Dark energy and dark matter shape the service architecture

A service architecture must resolve the dark energy and dark matter forces. The dark energy forces are the forces that push subdomains apart and encourage you to create fine-grained services. The dark matter forces are the forces that pull subdomains together and encourage you to create a monolith. These forces heavily influence the grouping of subdomains into services and the design of the service collaborations, which implement system operations.

About a service

Each service has a name, and responsibilities, which are what it knows and what it does. For example, the Customer Service knows the customer information, and manages their available credit.

A service has an API consisting of operations and published events. The Customer Service would, for example, define operations such as createCustomer() and possibly publish events, such as Customer Created.

A service also has dependencies, which are the services whose APIs it consumes. It invokes their operations and subscribes to their events.

A microservice architecture has an API Gateway

If the architecture has more than one service, it will also have an API Gateway. The API Gateway is a facade that expose the application’s public HTTP/gRPC/etc-based API. It implements edge functions, such as authentication, authorization, rate limiting, etc. and routes requests to the appropriate service. The API Gateway might also implement API Composition. It one of the several ways that a system operation is invoked.

The service architecture implements the system operations

The purpose of the service architecture is, of course, to implement the system operations. Each operation is implemented by collaboration of the services and typically the API Gateway. The collaboration is enabled by those services’ design elements, which include:

• API operations and published events
• Proxies that invoke operations on other services
• Event handlers that subscribe to events published by other services

Which particular elements that are needed depends on how the operation is triggered, whether the operation is local or distributed, and if it’s distributed, which service collaboration patterns are used.

How system operations are invoked

A system operation is invoked in one of several ways:

• A HTTP/gRPC/etc request to an API Gateway endpoint, which typically routes the request to a service, which has a service operation endpoint.
• A message published to a message channel that’s consumed by a (entry point) service that has an event handler, which subscribes to the channel
• A scheduling framework that is either external to the services that invokes an operation on an entry point service or embedded with a service, such as Spring’s @Scheduled annotation, that invokes a method on a @Bean

Local vs. distributed operations

In a microservice architecture, some system operations are local where as others are distributed. A local operation is an operation whose subdomains are in a single service. A distributed operation is an operation whose subdomains are in two or more services. Let’s look at how a service architecture implements a local operation.

Local system operations

The service collaboration for a local operation is very simple.

The system operation is invoked using one of the mechanisms described earlier. For example, if the operation is invoked via HTTP/gRPC/etc, then the API Gateway has an API endpoint that simply forwards the request to the service that implements the operation. The target service’s API has an operation endpoint that handles the request.

Distributed system operations

The service collaboration design for a distributed operation is more complex than for a local operation. A distributed operation is implemented using a combination of the service collaboration patterns. For commands, you use a combination of the Saga and API Composition patterns. And, for queries, you use a combination of the API Composition and CQRS patterns.

As with local operations, the system operation is invoked using one of the mechanisms described earlier. The key difference is that the entry point service collaborates with other services by making synchronous requests and exchanging messages, including events and asynchronous requests. The participating services have design elements that enable them to collaborate.

Operation realization

An operation realization is a subset of the architecture that implements an operation. It consists of the services that contain the operation’s subdomains along with their elements that implements the operation. An operation realization is an important concept because, as you will see in the next article, you incrementally define the service architecture by designing one operation realization at a time.

What’s next

In the next article, I describe how to design a service architecture using the Assemblage process.

Need help with accelerating software delivery?

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help