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.

Roundup #41: Apache Spark, Strongly Typed EntityIDs, Azure Workers, Automapper, NetCore3 Progress

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Introducing .NET for Apache® Spark™ Preview

Today at Spark + AI summit we are excited to announce .NET for Apache Spark. Spark is a popular open source distributed processing engine for analytics over large data sets. Spark can be used for processing batches of data, real-time streams, machine learning, and ad-hoc query.


Using strongly-typed entity IDs to avoid primitive obsession

Have you ever requested an entity from a service (web API / database / generic service) and got a 404 / not found response when you’re sure it exists? I’ve seen it quite a few times, and it sometimes comes down to requesting the entity using the wrong ID. In this post I show one way to avoid these sorts of errors by acknowledging the problem as primitive obsession, and using the C# type system to catch the errors for us.


.NET Core Workers in Azure Container Instances

In .NET Core 3.0 we are introducing a new type of application template called Worker Service. This template is intended to give you a starting point for writing long running services in .NET Core. In this walkthrough you’ll learn how to use a Worker with Azure Container Registry and Azure Container Instances to get your Worker running as a microservice in the cloud.


AutoMapper Usage Guidelines

A list of Do and Do Not for best practices if you’re using Automapper. I just saw that a new version was released and it made me think of this post.


.NET Core 3.0 – progress on bugs, weekly update from 4/24


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Using AWS Parameter Store for .NET Core Configuration

Parameter Store for .NET Core

One of the aspects I love about .NET Core is the new configuration and options pattern. In a continuation from my last post on using AWS Parameter Store for Data Protection keys, you can imagine it is possible to use Parameter Store for .NET Core Configuration.


There is a package by AWS that facilitates making using Parameter Store incredibly easy. Simply add the Amazon.Extensions.Configuration.SystemsManager package to your project and use the AddSystemsManager extension method on IConfigurationBuilder

The argument you pass to AddSystemsManager will be the prefix to your configuration hierarchy within Parameter Store. In my example, I’m using /Demo as my prefix, as you will also see below.

If you look at the first two entries, I can now create classes that match this hierarchy.


Next step is to add this configuration via the IServiceCollection using the Configure<T> method. Where T is our configuration type DemoConfig

This will add registration for the type IOptions<DemoConfig> so we can inject it in our Controllers or anywhere else the ServiceProvider is used.

This results in our config variable being set to the values from Parameter Store.

Parameter Store for .NET Core

If you have any questions or comments, please let me know on twitter as I will focus my posts on those questions and comments.

Related Links:

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.