Bounded contexts should contain just domain code?

Question

In Domain-Driven Design there's the idea of bounded context which is basically a way to stablish a boundary within which a certain model is valid as far as I understood. I've found this idea very useful because prior to reading about it one of the main challenges I've faced to use object orientation correctly was the existence of ambiguities on the model (a Product class which depending on the context might mean something different, for example).

Now, although I think I understood a little the idea of bounded contexts, I'm yet unsure on how to implement this on practice.

My main doubt, which is what I'm asking in this question, is the following: when we are coding a bounded context, it should contain just domain code or be an entire application?

In some readings I've got the impression that a bounded context referred to an entire application. But this seems not to be in accordance to the understanding I've got and to the fact that DDD deals with just the domain model. In truth, IMHO most of the time we are interested in building one application, and it happens that there are different contexts within each the terms from the ubiquitous language, although the same, means different things. In that case we do not intend to build several applications, but just one.

In that case, when implementing DDD bounded contexts, they should contain just the domain model for that context, or be an entire application?

Answer 1

If I'm understanding your question correctly, I don't think the bounded context has to be a separate application, though it may be.

If you were building, say, a hotel reservation system, you might have a "guest" context and a "hotel" context -- the Guest context might model names, addresses, rewards points, and the like; the Hotel context might model the properties, rooms, and so forth.

You could build those as two separate systems, perhaps as a set of Guest services and Hotel services that interact at carefully-defined points. Or you could build it as a single system, in which the two contexts inhabit the same codebase, but exist as separate, loosely-coupled packages or modules.

Either way, you're respecting the bounded contexts. Which path you choose would depend more on considerations such as product requirements, performance, scalability, team skillsets, and the like.

Where you would start to go wrong, of course, is if parts of the bounded contexts started to leak into each other -- if a class in the Hotel context were storing a Guest's room assignment, for example, that sounds like trouble.

You could, however, have a "Reservation" model that straddles the Guest and Hotel contexts. Again, though, this could all be part of the same codebase and application, or they could be separate applications that interact with each other. I would say that is an implementation detail, albeit an important one.