Skip to content

Context is King: Finding Service Boundaries through Language

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


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.

Context

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.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


Leave a Reply

Your email address will not be published. Required fields are marked *