Thanks to the GSAS I had the opportunity to attend the workshop “Architecture, the hard parts” taught by Mark Richards. For those who don’t know him, Mark is a software architect specializing in Service-Oriented Architectures. It was one of the best workshops I have had the pleasure to attend.

In this workshop, Mark showed us the differences between the different types of monolith and distributed architecture. It provides us with extensive examples based on real-world cases and when to implement each of them and also possible solutions to tradeoffs.

There is no perfect software architecture for a project, it always depends on the needs of your business to decide which one to adapt. Today I would like to talk about service-based architecture.

Service-based Architecture

A Service-Based Architecture is a software architecture that is defined as pragmatic and distributed, an intermediate point between a Monolith Architecture and a Microservices Architecture.

Compared to fully distributed architectures it consists of several differentiating points in which it is worth highlighting the granularity of the services and the scope of the database.

Unlike Microservices, components are more flexible and less atomic. This enables more complex business operations and improved orchestration and transaction issues by grouping multiple modules.

Database is a shared resource, which improves performance by reducing calls to other services to access data.

In return, refactoring an entire database may not be possible. Changes to a table are a little more difficult when you create a coupling to the data schema.

In addition, services will not be so atomic making them more difficult to develop and test. Launching a new version requires more planning.

However, if we compare it to a monolith architecture we will get significant advantages such as the decoupling between modules, better control over development, stability and scalability. Allowing you to win the time to market.

In short, we will get a robust architecture, easy to understand, well organized with components that can be recomposed, adapted and scaled independently.

Adopting Service-based Architecture

To adopt the service-based architecture, it is not enough to divide the application into small components. A modularized architecture in very large parts can lead to orchestration problems and interdependence between services, however a very grainy one in small components and can lead to transactional problems.

There are many ways to migrate software architecture, but a basic way would be as follows:

– Change the package structure of technical layers in domain layers of our monolith. For this case we can make use of DDD patterns such as Aggregate or Bounded context. In this way we not only divide the structure but reduce the cost of change.

– Identify the contexts of our application

– Group domain packages into components by:

• Business functionality groupings: As the name implies, it would be grouping components by application capabilities.
• Transactional boundaries: One way to identify transactional boundaries is if each time in a request we have to update two components: the item and the inventory (account and customer), maybe we should join those components.
• Deployment goals: In certain circumstances we find that one component is constantly changing and the rest of the application is not. This is an indication that we should extract that component as a deployable unit.
• Scalability needs: Sometimes we need to improve the performance of a specific component or use case.

Iterating these steps, which involves decoupling as much as we can and taking into account that the greater distribution and granularity increases complexity, we can get the right architecture.

And as Mark Richards said:

“Embrace modularity, but be cautious of granularity.”

Have a look at our testimonials (in spanish):