Bounded Contexts

[00:00:00]
>> Mike North: The next topic we're going to talk about is what domain driven design describes as bounded contexts. You could think about a bounded context as kind of an area of a problem space or a domain model where a ubiquitous language, a common shared language applies, and there is internal consistency within a bounded context.

[00:00:27]
So, for example, if you had a very generic model name like item, where maybe we consider there's an item planted in a raised bed and it happens to be a plant, or maybe item means other things in other contexts. The purpose of this bounded context is really to create a bubble where you don't have to add all these namespace qualifiers where you're like, this is a grid placeable item with ID and metadata.

[00:01:00]
That's what we're going to call our class for a particular entity. Part of the value of this is it's almost like identifying a related family of entities and their relationships and their constraints that you can kind of draw a circle around and say, this is a neatly bundled thing.

[00:01:20]
And like TypeScript Monorepo's course, we might consider making this a separate package because there's some self contained complexity there and we can use simple terminology while always noting we're operating within that context. Well, it turns out that there's another context in this app beyond sort of seeds and plants.

[00:01:46]
There's the context that has to do with this user interface, which we're about to start working on for being able to drag plants into raised beds and arrange them and get some feedback based on our planting. Our UI has a model that looks like this. We have workspaces, zones, item placements, and those item placements relate to items.

[00:02:09]
So you could think of this as sort of. It's a very generic ui. Like you could use this same drag and drop UI to build a chess game or something like that. In essence, it's a grid with draggable tiles that are placed at XY coordinates on a grid and maybe they relate to a chess piece.

[00:02:32]
So we might have a model of like bishop or knight or pawn, and that would be part of the visual representation of that thing on the grid. And maybe there are multiple grids and you can move things across chessboards. For some reason, the analogy's breaking down, but the UI has no idea about this gardening concept.

[00:02:53]
And so what we would say is, well, that's a bounded context. Item in this case is just like in this world. Well, we've since interfered with our plant construction here, but in the world of the gardening app here, it's just sort of like these things that you can drag onto the grid like it's the pepper plant or it's the cherry tree or whatever it is.

[00:03:19]
And so we're about to create a gardening related, bounded context of our own that will involve sort of, at its root, we may have this concept of garden, but there are different beds in that garden and plants within those beds. And so we're going to have to model all of that.

[00:03:42]
But we can say the terminology we're going to use when speaking garden belongs in that bounded context. And when we're speaking about grids and workspaces and zones, that belongs in the other context. All right, but how do we bridge those worlds? Well, we need what's called an anti corruption layer.

[00:04:03]
This is like DDD terminology, but you have built these before. It effectively is a way to keep clean modeling in two areas. Or sometimes you have clean modeling and very dirty modeling in a legacy code base or something. The anti corruption layer is a very closely scoped layer that you use to kind of convert between the important domain models that are at the essence of the app you're building and whatever else they need to talk to.

[00:04:36]
Right. This is what's going to avoid kind of contaminating our garden and our raised bed and our plant and our seed packet with the drag and drop UI concepts. And we have this already right today. It kind of exists in the route handlers where we're adapting between what our domain services spit out, like a seed packet and the HTTP response that needs to be passed back up to our user interface.

[00:05:04]
So you might argue that's kind of an anti corruption layer. It would be even cleaner if we were to say, you know what, we're actually going to turn some of that transformation, we're going to refactor it into functions, and we might create a new package that purely serves as this layer to adapt between our domain services and what the UI wants to get.

[00:05:26]
And then the request handling is just sort of leveraging that and we can further separate concerns that way.