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!


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.


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.


Serverless and Agile

Agile and Serverless go together like peanut butter and jelly. Ham and eggs. Coffee and creamer. Tea and milk. Name your favorite combination that resonates best in your head. But the truth is this, Agile and Serverless are a great pair when it comes to delivering value quickly to your customers and sets a foundation for adapting to change. And isn’t that the point?


Becoming a Leader in Tech

I had several conversations at re:Invent that have got me thinking since I returned. No names or details will be given about those whom I spoke with, but I have been processing the how and why of one’s career arc. How does one go from individual contributor to say Director level or even one day become a CTO? Breaking down the trajectory I’ve come away with a couple of types of leaders. In this article how to become a leader in tech.


Gratitude. A look back at re:Invent

Gratitude. That’s the simple yet powerful word that comes to mind when I look back on re:Invent 2023. This article is an expression of my gratitude to those who made not only re:Invent something more for me this year, but have jolted my career in a way I didn’t know was possible.

This year started with a blast to my system. My father, who was my best friend in life passed away after a long bout with cancer. I was there for his last month and spent time with him while he was with us. I can’t say I enjoyed the time, but we took the time together talking, sharing and trying in general to do whatever I could to make things easier for him. Growing up watching my father run his own Geology Consulting Practice gives me a unique perspective now as a father. His schedule allowed plenty of flexibility to attend my golf matches, soccer games and occasional theatre productions which left a lasting impression on me. Those 20 or so days of my life have reshaped my trajectory forever.


Embracing Bad News as a Leader

Some find that handling bad news as a leader is tricky. Their first thoughts range from figuring out who to blame, how to hide the damage or even just how to make the problem go away. I like to look at it from a different perspective. I want to embrace bad news. Treat it as a learning experience for those involved. And ultimately use it as an opportunity to build trust.

Follow along as I give you a few tips on how to embrace bad news as a leader.


Building Trust

I’ve been spending a lot of time lately being self-reflective and this week I was thinking about building trust. The more I thought about trust, the more I wanted to write something about how to build trust with your team, lead or even boss. I’ve got a unique perspective having been a team member, team lead and lately the head of a department. Trust is something that takes time to build and an instant to destroy. But once you gain it, pairing it with influence and credibility is a powerful combination for you as a technologist. Let’s dig into building trust in a technology team.