Context is King: Finding Service Boundaries through Language

I’ve found that one of the most important ways to find service boundaries is through the dialog you have with various end users in different parts of the system we are working on. Really focusing in on the words they use can be instrumental in finding service boundaries.

This blog post is in a series. To catch up check out these other posts:

Taken out of Context

If a statement or remark is quoted out of context, the circumstances in which it was said are not correctly reported, so that it seems to mean something different from the meaning that was intended.

If was talking with my son, and you overheard the statement:

The crane was huge.

Which crane would you have thought of?

There really is no way for you to know which type of crane I’m referring to without more context.

A Product isn’t a Product

As a more practical example, let’s use a distribution company.

The high level is the company purchases products from vendors, receives them into their warehouse, and then sales those products to customers.

When you talk about a product, it can mean different things to different people depending on their context.

If you talk about a product to a salesperson, when they use the word price they are referring to is the sale price. Sales are customer-centric.

When you then discuss a product to a person in purchasing, they will refer to the products price as the vendor price since purchasing is vendor-centric.

Talking about that exact same product to someone in accounting, they will refer to the price as the sales price, and cost as the vendor price.


By understanding the context of the end users of the system you can determine when a word may mean different things to different people. If it does, then you may have found a boundary.

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.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Context is King: Finding Service Boundaries

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.


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.


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…


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.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Explore DDD 2017 Review

I just returned from Denver, Colorado, where the first Explore DDD conference was held.  I originally heard about it earlier in the year on Twitter via the organizer Paul Rayner and decided to submit a couple abstracts for the CFP.

Fat Controller CQRS Diet

The talk that was accepted and which I delivered on Friday morning was my Fat Controller CQRS Diet talk.  The talk revolves around trying to decouple your application from top I/O layer or framework.  More info on the talk can be found in my series of blog posts as well as a episode of Software Engineering Daily podcast.

Domain Driven Design

I stumbled upon Domain Driven Design somewhere around 2010.  I actually found it because of watching a talk online from Greg Young making some indirect references to Domain Driven Design and CQRS.  The talk caught my interest and within no time I was captivated by DDD and CQRS.  I instantly went and purchased the book.  That was a very significant point in my software development career.

Explore DDD

The speaker lineup at this conference was simply incredible.  Eric Evans, Rebecca Wirfs-Brock and Ward Cunningham were the keynotes.  Crazy. I cannot really believe that I was chosen to speak at such a conference. Imposter Syndrome was maxed out to 11. It didn’t take too long to have some conversations at the conference to realize that I had different experiences and views that proved to be valuable.  This didn’t knock down the imposter syndrome completely, but definitely lowered it a just a tad.  On the other hand, the amount that I learned from discussions and talks were like no other conference.


This really summed it for me.  There was a real sense of community/family.  I can’t really put my finger on why that is but I have a few guesses.

Conference Space/Location

Incredible.  38th Floor of the Grand Hyatt, looking over downtown Denver.  The floor itself was broken down into 3 track rooms, general gathering room where food was served, as well as a unique blue track room.  The blue track was reserved for spontaneous modeling, discussions, problem solving, whatever.  I actually had several interesting discuss here and it was kind of a good place for the “hallway” track in some respects.

Paul Rayner

The conference kicked off on Wednesday evening with the keynote by Eric Evans.  Paul spoke to intro the conference as well as each day with some house keeping notes.  I felt the way Paul gave such a calm welcoming, really set a tone for the entire conference.

Thank You!

Hands down an awesome conference.   Thank you to Paul for organizing an incredible event and selecting my talk.  All the attendees and speakers (from all over the world!) for making it feel like a family. I highly recommend attending this next year.  I hope to see you there!