Bounded Context

[ryan-mars]

• Emits public events via EventBridge BoundedContext: Public events are published to Event Bridge #28
• Publish schemas for public events to EventBridge schema registry BoundedContext: Publish schemas to EventBridge schema registry #15
• Can subscribe to events from another bounded context BoundedContext: Can subscribe to events from another bounded context #20
• Has an event store, forwarder, and topic Bounded Context: Event store, forwarder and stream #29
• Has a unique name (don't allow two bounded contexts in the same AWS account with the same name)
• Tags all resources associated with it Resource tagging #67
• Cross account event bridge Cross account event bridge #66

Bounded Context

Organisations don’t usually have consistent languages to describe their domain. Silos actively fragment knowledge into locally consistent bubbles, but end-to-end language consistency is usually a myth. The larger the organization, the more specialized jargons thrive around a specific function.
A Bounded Context is a unit of language consistency, a portion of the model that guarantees that every term has one and only one meaning, greatly improving our modeling precision.

A few clues about how to effectively partition a system:

• We’ll see where people tend to be, and usually different people tend to have different specific needs
• We’ll see boundaries, between different phases and swimlanes, often pointing to different needs.

Credit: Alberto Brandolini

[ryan-mars]

Thinking out loud...

An event storm may contain multiple bounded contexts. In many instances a bounded context will be synonymous with a single app (micro service). However, this will not always be the case. Additionally a single serverless app often consists of multiple CloudFormation stacks in order to decouple the deployment of less frequently changing or security sensitive resources.

The concept of a CloudFormation stack should not leak into the Event Storming abstraction, but on the infrastructure side a developer should be able to reasonably partition how resources from the event storm are deployed. For MVP each Bounded Context might want to have it's own Cloud Formation Stack. This is because a Bounded Context is often synonymous with a team. If an Event Storm = CloudFormation Stack this could be bad. I don't think multiple teams are going to want to work in the same stack.

Furthermore, it would seem that if Bounded Context = a team it makes sense for each Bounded Context to be in its own CDK App.

[sam-goodwin]

Can we make use of nested stacks here? Can bounded contexts be nested/recursive?

How should we deal with the resource limits in CloudFormation? Do we use that limit as friction, to encourage teams to break up a large event storm into smaller more managed pieces, or do we implement an algorithm that topologically sorts the graph and then automatically creates other nested stacks to account for limits?

I think friction is an easier way to start. But it has risks with regards to different interpreters. Pulumi, cdk and terraform all have different constraints. So it's possible that an event storm can be interpreted by pulumi but breaks in cdk (for example).

Should the EventStormConstruct provide properties to influence stack creation? Each bounded context could be parameter used with a StackCreationStrategy.

[ryan-mars]

Can we make use of nested stacks here? Can bounded contexts be nested/recursive?

At some point, some org is going to want to do this. I'd really like to avoid it. I don't think nesting will end well for anyone. Renaming a BoundedContext could be a big pain once in production, I imagine a re-org would become doubly painful. My instincts tell me Bounded Contexts should remain as flat as possible.

How should we deal with the resource limits in CloudFormation? Do we use that limit as friction, to encourage teams to break up a large event storm into smaller more managed pieces, or do we implement an algorithm that topologically sorts the graph and then automatically creates other nested stacks to account for limits?

Oh God. Let's punt on that until it becomes an actual problem for someone. I want to see the actual use case there before we start partitioning resources into nested stacks on behalf of the developer. 500 resources is a lot. Ideally we'd leave it to them to decide what resources go in what stacks, but thinking more deeply about it that could get complicated and might cause problems if they don't understand stochastic internals.

I think friction is an easier way to start. But it has risks with regards to different interpreters. Pulumi, cdk and terraform all have different constraints. So it's possible that an event storm can be interpreted by pulumi but breaks in cdk (for example).

Should the EventStormConstruct provide properties to influence stack creation? Each bounded context could be parameter used with a StackCreationStrategy.

I'm not saying BoundedContext = Stack. I'm suggesting Bounded Context = Team, and team usually means a package. Like if you look at the Software Model that came out of our event storm. Imagine each of those bubbles is owned by a team. They wouldn't want to be stepping on each other in the same package.

What if we simplified the language by making the top level component a BoundedContext instead of an EventStorm? Event Storming is a practice, a Bounded Context (along with the other component types) are software design concepts that have existed in Domain Driven Design for ages.

[ryan-mars]

If the top level component was BoundedContextConstruct it makes it easier for us to come up with a strategy for how a BoundedContext in one package can subscribe to events from another package once deployed. We need to figure out how the Loyalty team (with their own package) gets types at compile time and subscribed to events at runtime from the Operations team who have their own package and separate CDK app.

The only shared resource across all the BoundedContexts would be an EventBridge bus I suppose. So maybe some shared services team would own that.

[sam-goodwin]

What if we simplified the language by making the top level component a BoundedContext instead of an EventStorm? Event Storming is a practice, a Bounded Context (along with the other component types) are software design concepts that have existed in Domain Driven Design for ages.

Agree with this.