Context is King: Finding Service Boundaries

Having explicit service boundaries is one of the tenets of SOA. Defining correct services boundaries is critical. I believe it’s one of the most important aspects of developing a system is finding service boundaries and it’s also really easy to get wrong.

This blog series is intended as a guide for finding service boundaries within a domain for the system you’re developing.

What’s a Service?

Before I get too far ahead, I better clarify what “service” means to me so we can be on the same page. If I can simplify it to a single sentence it would be:

A service is the authority of a set of business capabilities.

A longer explanation is a service owns all the business logic and data associated with a specific set of business capabilities in our system for our domain.

Here are some of the topics covered in this series.

Data Authority

Services should have full authority over the data they manage. The data that they manage should pertain to the capabilities it provides. No other service should be able to directly access or modify the data. If there is no capabilities provided by the service, it shouldn’t be a service, just a database.

Autonomous

Services should not rely on other code. They should be independent of each other. Prefer asynchronous messaging over RPC.

Services react to messages. The publisher of those messages doesn’t need to know if they were handled. The consumer of the messages does not need to know how they were created.

If RPC is required, create well-defined interfaces for your service.

Language

It’s always amazing to me that language can have such a giant impact on understanding a domain which can help to define boundaries.

My classic example is using a warehouse/distribution system that has a Product entity. A Product isn’t a Product isn’t a Product.

Meaning a product in one service can represent an entirely different set of data capabilities in another.

Which then leads me to entities…

Entities

I’m not sure where the industry got fixated on entities. Domain Driven Design might be partly to blame for this. It also could be the likes of ORM’s and having mappings to tables that represent entities.

Whatever the reason, I think they do a giant disservice by taking away focus from what really matters which are business capabilities, not entities.

Blog Series

More on all of these topics will be covered in greater length in other posts. If you have any questions or comments, please reach out to me in the comments section or on Twitter.

Follow @codeopinion

The post Context is King: Finding Service Boundaries appeared first on CodeOpinion.

Blog