What are contexts?

- [Instructor] Now let's get into the nitty-gritty details of what a domain-driven design actually looks like, how is it structured. When you're thinking in DDD terms, you're thinking about organizing the code along certain well-defined boundaries. And the first of those is the thing called a Bounded Context. The idea of a Bounded Context is that it is a natural division within the business. So for example, if you were doing a bookstore, the store itself is a context. The purpose of that context is to sell books to people, but there's another context in order to make a bookstore work and that's the warehouse from which the books are shipped. So we have two distinct contexts here. One of them is the store and the responsibilities of things within the store context is primarily sales. And the other one is the warehouse, and the responsibilities within the warehouse context are shipping. And that's an important way to keep contexts separate from each other, is think in terms of what are the responsibilities of the people working within that context? If somebody went to work in the morning at the warehouse they would not be thinking that my job is to sell books, and the same happens over on the store side and somebody who works in the store is not going to be thinking I need to know how to ship books. So within each of the contexts you have distinct people working, and they are working within their context without thinking too much about other contexts. Now of course in order to do that, they have to communicate with each other. And the communication is for the most part entirely within a given context, which is one of the reasons why domain-driven design makes for a good design principle. 'Cause things that happen inside the context stay inside the context. Things go wrong when you end up having objects that are on both sides talking to each other without any regard to the context boundaries. So that's something that clearly you want to avoid. So, the way that DDD solves that problem is by allocating responsibility for communication between context to one small object. In other words, in this picture on the store side we have one person, if you will, whose job is to talk to one person on the warehouse side in order to communicate between these two contexts. And this is the way it usually works in the real world. If you need something to be done in the accounting department you don't walk over there and just grab a random accountant by the collar and say do this for me, there's a process that you have to go through that involves going through proper channels in order to communicate. And all that we're doing in a DDD world is modeling that notion within the code itself. So, let's look at a little bit of terminology here though. An individual person, if you will, within a context is known as an entity. So an entity is a lot like a object or a class in the object-oriented world. It has one job and it does only one thing, and that thing is done in a specific context. So an entity is of course interesting, but of more interest is the notion of an aggregate. So the idea of an aggregate is an aggregate is a collection of entities that you talk to through a single portal. So this large guy here is the portal for the aggregate. Now, the line between an entity and an aggregate can be kind of fuzzy because from the outside world the portal into the aggregate looks like an entity, it looks like one object that does one job. However, when you start focusing in on the code itself, then you start seeing the entities that that portal entity uses to actually get the work done. So whether something is an entity or an aggregate may not be obvious from the outside. On the other hand when you drill down, if it's an aggregate there are things inside the aggregate that are used for the entity that controls access to actually do the work that's requested of the aggregate as a whole. Contexts are often implemented as single aggregates, but they might not be. A context might actually be implemented by multiple aggregates that are working together in order to get their work done.