Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Udi Dahan on Defining Service Boundaries

Udi Dahan on Defining Service Boundaries

Udi Dahan, a SOA consultant, held the presentation Finding Service Boundaries – Illustrated in Healthcare at NDC London 2014, providing advice on establishing the service boundaries in a SOA or microservice architecture.

According to Dahan, a service is the “technical authority for a specific business capability,” all related data and business rules residing within the boundaries of the service. He considers this approach important in order to create proper alignment between the problem domain and the solution domain. Other services should not be able to directly access and modify a service’s data, but rather use the service for that purpose. Also, no data is left by itself, because any system’s data exists to serve a business capability, so it should be encapsulated into a service.

Dahan mentions several principles used in service orientation architectures:

  • Services are autonomous
  • Services have explicit boundaries
  • Services share contract and schema, not class or type. Other than pure communication between them, services do not share access to resources, including databases, because this might introduce dependencies between them.
  • Service interaction is controlled by policies

Services own their data

Dahan considers that a service has to have both some sort of functionality and some data. If it does not have data, then it is just a function. If all that it does is performing CRUD operations on data, then it is database. He considers that a database should not be made a service just to provide basic operations on data through RESTful calls because these introduce supplementary layers that are not needed. SQL is good enough.

Services should be loosely coupled

When defining service boundaries within a system, Dahan suggests attempting to minimize the coupling between services. Microservices do not have to be built around aggregates or even entities but around their attributes. In other words, an entity’s boundary is not necessarily a service’s boundary. He gives as example Amazon’s approach to building a web page for a product. Amazon uses dozens of microservices serving up small widgets that are composed to create the product’s page. One such widget may contain the title of the book, another the price, another the link to reviews, etc. They all refer to the same book, but the microservices are not built around the entity Book but rather its attributes, all sharing the same identifier. The microservice can have ownership of a simple columnar database containing the identifier and the respective attribute’s value. Such an approach lowers the coupling to a minimum but leads to an increased number of microservices and the problems associated with their management. Dahan does not see any problem for services keeping their data in the same shared database as long as each service has its own schema.

This approach is possible for attributes that have no other relationship than belonging to the same entity, so they would never require a joined operation applied to them. If modifying the value of one attribute involves changing the value of another, then those two attributes should fall under the responsibility of the same service.

Also, it is possible for a service to operate on attributes belonging to different entities, if the operations on them are directly related.

Services should not exchange raw data over Pub/Sub

A step further in making services autonomous is using a Pub/Sub protocol which loosens the coupling between services. But services should avoid exchanging events containing raw data because this may lead to temporary data inconsistencies. Two services may have different values of the same data because a data change has not managed to propagate to all those interested. Pub/Sub should only propagate events on operations, such as “order xxx has been accepted”, containing its identifier but without the actual value of the order. Each service is to remain the authoritative source for its data, and it should not yield it to a Pub/Sub event, even if it is temporary.

It usually happens for a data to be duplicated at the UI level. To avoid sharing a data between multiple sources, Dahan recommends building the UI with components or widgets that are each related to one service and not to multiple services. One service may have multiple widgets, but each widget may have only one service.

Services should remain the authoritative source of data even across systems

Enterprises may build multiple systems –back-end, desktop, mobile, etc. – accessing the same data. Dahan recommends that the same services should provide their respective business capabilities for all of these systems. Although the systems may be built using different technologies and languages, they should share the same services.

Service boundaries in healthcare

In his presentation, Dahan uses the healthcare domain to exemplify how to approach modeling the domain and finding the service boundaries. Dahan observes that in healthcare the “context is king.” There is a different approach to medication, history of treatments, allergies, etc. in various contexts: personal doctor, emergency, dentist, psychiatrist, physiotherapist, or delivery room. Dahan suggests starting by modeling the domain one context at a time disregarding the other contexts. After that, observe the similarities and differences between contexts, and extract the elements that are common to all of them, such as patient or billing. Create a service for each context or common element.

Dahan advises to apply the single-responsibility principle, minimize data passing between services, and avoid high coupling.

Rate this Article