The Neighborhood Domain will Quickly Improve your Modeling Skills

Microservices are about domain decomposition. This decomposition allows code to be deployed that is more isolated, durable, resilient, and launched in a compute form factor designed for the requirements. In addition, the isolation allows for teams to move on their deployment schedules and cadences. These reasons are attractive, but they do come with domain complexity that often manifests itself as architectural complexity. And while I can’t remove the architectural complexity, I do want to offer an approach to domain modeling that will feel more familiar. Introducing the neighborhood domain.

Domain Modeling

Modeling a business domain is one of those tasks that everyone agrees is important but often gets overlooked when it comes time to implement a new software solution. Speaking from experience though, skipping this step will create confusion and miscommunications that can become both costly in time as requirements are written and also costly in rework when things aren’t implemented in congruence with what the domain is. Software systems operate better when they look and sound like the businesses they model.

When doing this modeling work, an order of business that a domain modeler or architect must do is look at the macro picture of the business solution and begin to carve out boundaries. Boundaries in the domain world are often referred to as bounded contexts. A bounded context can be defined as a grouping of related microservices that operate to perform a set of functions on a user’s behalf. Bounded contexts are made up of multiple aggregate roots that form a collective bond which solidifies the ubiquitous language that a group of people operate within.

That’s a lot of words that can often be difficult to wrap your head around. When modeled, it often looks like this.

Bounded Context

A more Neighborhood Domain Way

The above diagram shows two bounded contexts representing a single solution. The example is basic, but the concepts apply to more complex examples as well.

An Orders bounded context deals with a user adding items to an order and submitting a payment. These boxes represent individual microservices that perform their operations and work in concert to deliver the intended functionality.

In a neighborhood domain, that same user also exists in the Users bounded context. The operations and behaviors in this domain deal with preferences, previous orders, and notifications that the user must manage. It’s still the same user as in the orders domain, but just in a different context. It will also be a separate microservice that is deployed and built from a different codebase than the one that is in orders.

Introducing the Neighborhood Domain

Take what I’ve written so far and the two bounded contexts described and let’s think of them more as neighborhoods. A neighborhood domain will contain the same thing as a bounded context with multiple aggregate roots but let’s describe it with concrete things we can all agree upon.


Let’s get a little bit more concrete as I introduce this. A neighborhood is a collection of microservices that are related to performing a set of user-expected operations. They work together to accomplish shared tasks. It’s very much like a community. It’s a boundary that all of the homes collectively reside in.

To make this a little bit more concrete, a neighborhood in AWS is managed by one of the following:

  1. Application Load Balancer
  2. Network Load Balancer
  3. API Gateway
  4. Route 53 Hosted Zone

The neighborhood is the top-level piece of a neighborhood domain.

House as a Microservice

If a neighborhood has no houses, is it a neighborhood? In the neighborhood domain, houses are the microservices. A house has entities that live in it and those entities perform operations and tasks.

What makes a house though a part of the community is to be associated with a neighborhood. The house could be implemented as a container hosted in EC2, ECS, or EKS. Or the house could be a series of Lambda Functions or even something like LightSail. If we carry this even further, houses need roads to connect them to other neighborhood properties. Those relate to API Gateway routes or Load Balancer rules.

Some Lagniappe

I’ve been talking so far about another way to think about bounded context and aggregate roots, but I’ve also been mixing in concrete items like AWS services to drive the points home. I want to give you a little something extra or “Lagniappe” that will further extend the harmony that is a multi-domain business solution.

In the USA, Home Owners Associations (HOA) have become common governing bodies to make sure that homes and their owners stay within a certain set of approved bylaws. These bylaws enforce the way neighbors keep their homes in the community up to standards.

I know what you are thinking right now … where in the world is this going? I’ll tell you.

Services often need to talk over APIs to other services. What’s to prevent a service from being a “noisy neighbor” or a neighbor that doesn’t honor the rules of the community?

Enter the service mesh. A service mesh operates as an HOA in a neighborhood to set some common guidelines about how services will talk to each other and protect the neighborhood from a house that’s not operating under the bylaws.

Bringing it All Together

The neighborhood domain is just another way to think about a 20 + year-old concept that was introduced by Eric Evans in his book Domain Driven Design.

When looking at complex domains as neighborhoods, this is what the original diagram would look like.

Neighborhood Domain

Neighborhoods, houses, and HOAs are constructs that you can use to model the bounded contexts and aggregate roots that exist in your world.

Wrapping Up

This was a much different article than what I normally write about. The genesis though was some work I was doing with a client recently and when trying to help them break up a large domain, the concept of neighborhoods showed up. Bounded contexts and aggregate roots are tough to explain, but neighborhoods, well everyone knows what those are. Getting people to rally around communities of homes operating together to serve a user’s purpose makes the work of building a ubiquitous language that much simpler. And as an architect, building that language is much more important than many give it credit for.

I hope that this new way of thinking about domain modeling will give you another tool to build amazing software that delights your customers. Because remember, software needs to be either fun or useful. If neither, then why do it? And most importantly, software is a team sport. And working as a team makes everything go better, faster and more efficient.

Thanks for reading and happy building!


Secure Pattern for Deploying WASM on S3

Picking up where I left off from the last article, I’d built a simple WASM project with Rust and walked through how to generate a publishable distribution. In this edition, which is probably the penultimate in the series, I need to get a path towards CloudFront and S3. I want to stay true to the Serverless objective and those two services are perfect for shipping web-delivered code. So let’s dive into Deploying WASM on S3.


Surprisingly Powerful – Serverless WASM with Rust Article 1

It’s been a while since I wrote a series going back almost 9 months to my Building Serverless Applications. I enjoyed that so much that I have been wanting to write another, but just didn’t have a continuous thread of material. But lately, I’ve been thinking a lot about “full stack” development and where the future of delivery is going. Some of that thinking has led me down a path of what if. What if I was able to use my favorite programming language and my preferred AWS Serverless tools to build full-stack web applications? I’m not 100% sure I’d do this in production at the moment, but again, I’m exploring what if. This series is the expansion of that thought. Let’s get started on Serverless WASM with Rust.


Guaranteed Safety using Blue Green with ECS and CDK

Buckle up for this one as it’s going to be a lengthy piece. I love writing articles like this one because they contain complete infrastructure builds that highlight some best practices to put multiple components together and act as great starting points for people to use immediately. I’ve been working a great deal with containers lately and I kept finding it difficult to locate a working sample of building Blue Green with ECS and CDK. So I set out to put that together. Let’s get started.


3 Proven Patterns for Reporting with Serverless

Serverless architecture has given developers, architects, and business problem solvers new capabilities to deliver value to customers. It feels like we are in the age of maturation of serverless in so many ways. The boom of containers, the birth of functions, and now the options of even Zero-code serverless implementations (Step Functions). These are all great things from an application developer’s perspective. But what about reporting? There are so many signals emitted from these systems but has the reporting world kept up with the changes in architecture? And what are some strategies to take advantage of data in this current landscape? Let’s have a look at Reporting with Serverless.


An Allow List Lambda Function in Rust is 1 Guaranteed Way to Improve CORS

Some time ago I wrote an article about Cross-Origin Resource Sharing with API Gateway that talks about custom allow lists. I wanted to revisit that implementation not because the code doesn’t work, but because I wanted to see what it would look like in Rust. Remember, I believe that more developers would be choosing Rust with Serverless if more content and examples existed. Let’s dive into building a Lambda Function in Rust for CORS.


A Proven and Comprehensive Pattern for Building an API with Rust and Lambda

I’ve been encouraged lately by all of the Rust and Serverless content that has been posted on various platforms. I’ve also been public about the fact that I believe that Rust adoption with Serverless would be further along if there was more quality content written on the topic. I know for certain that there is interest from developers about whether they should and how would they introduce Rust into their builds and while I’ve tackled pieces of the puzzle, I haven’t taken on a fully working CRUD API. This article looks to change that. Let’s dive into building an API with Rust and Lambda.


4 Inspiring Tips to Think like a Consultant

I’m early on in this new venture as a full-time consultant but something that isn’t new for me is being someone people go to for help. Every time I speak to someone about this topic I tend to drive back to the same core concepts that I’ll talk about below. Being a consultant isn’t about rates, engagements, or hustling for business. Sure, it can be a career. But being a consultant is a mindset that can elevate your position and influence first in your team and then more broadly into your organization. Following along I give you 4 tips to think like a consultant.


Embrace that a Career isn’t always Measured by Climbing the Technology Ladder

What if I’ve been thinking about my career all wrong up until this point? How can that even be possible? I consider myself to be making the turn. Heading into the back nine of this adventure. Does that mean that I’ve wasted the first 9 holes of my technology career? These are heavy questions to explore but ones that I needed to address as I grabbed that metaphorical snack and made my way to the 10th tee. I realized this one important thing. My career isn’t defined by how high up the technology ladder I climb, but by the story I tell through the canvas I’m painting. I believe that this notion of climbing the technology ladder isn’t the only way to measure success.


People Matter more than Technology when Building Serverless Applications

I’ve been hitting the gas pretty hard on Rust lately and doubling down on my desire to see more Rust in Serverless. I feel strongly though that balance is important in anything in life. For every period of intense push, there needs to be time to pause and reflect. So for this article, I want to take a step back and hit some brake on my Rust content by looking at what’s really important when building Serverless applications.