Understanding SoA

Microservices are an evolution of the Service Oriented Architecture (SoA). So, if we want to understand what a microservice is, we need to understand what SoA is. SoA is based on having application components communicating through a set of services, a discrete unit of functionality that can be accessed remotely. Services are the foundation stone in SoA, and the same applies to microservices as well.

As described in SoA, a service has four properties:

• It logically represents a business activity with a specified outcome
• It is self-contained
• It is a black box for its consumers
• It may consist of other underlying services

To understand these properties, let's look at an example of an application using SoA:

In this typical n-tier architecture, the application is divided into three layers:

• Presentation layer: Holds the UI for our customer
• Business layer: Has services implementing the domain logic for our business capabilities
• Data layer: Persists our domain model

Each component includes the logic to interact with the customer in a specific business activity and to do so, uses the services provided by the business layer. Each service represents the realization of a business activity. For example, you log in to the application provided by the login service, check offers provided by the offers service or create orders via the orders service. These services are self-contained in the business layer, and they act as a black box for their consumer—the components don't know how the services are implemented, nor do they know how the domain model is persisted. All the services depend on the customer service to obtain customer data, or return customer information, but the client does not know about these details.

This approach provides several benefits to any architecture that uses it:

• Standardized service contract, allowing easy integration with components
• Reusability, allowing services to delegate responsibilities to each other
• Business value, implementing the business capabilities
• Hides complexity; if we need to change our database, the clients are unaffected
• Autonomyl; each of the layers could be separated and be accessed remotely