What's the process you use for determining bounded context in DDD?

Question

I've been through a few iterations of DDD with a few different projects, yet I still struggle with properly defining bounded contexts. I continually find myself wanting to create very granular aggregates. This has become even more true once I've introduced event sourcing into the mix.

Here's a concrete example. Let's say I'm designing a piece of software like photoshop. From the outset, I can see i'll have a domain object for the Design. Now everyone says don't design domains that can't stand on their own. This is where I struggle. If I wanted to add a feature to my photoshop-like application to support multiple layers in the design, the concept of a layer doesn't make sense outside of the Design. It doesn't "stand on its own". So that seems to me like it should be a value object of the design. Same thing goes for the actual graphic elements that may be included in a layer. But that doesn't make much sense either, because Value Objects should be immutable.

I'm beginning to wonder if I am interpreting the phrase "stand on its own" incorrectly. Does this actually mean, the domain object can be manipulated outside of the context of the other domains. What I'd prefer to do is make Design, Layer, and Element all their own Domain Objects, who hold references to each other by Id. Since I'm heading down the ES path, I would then publish the events of the affected domain, and a listener would update the relationships between those domains.

Is there a different path I should be on or a different interpretation of DDD?

Answer 1

There's indeed some confusion round there; the term "stands on its own" is too fuzzy to be helpful.

First, two basic DDD definition given in Evan's book:

VALUE OBJECT: An object that describes some characteristic or attribute but carries no concept of identity.

ENTITY: An object fundamentally defined not by its attributes, but by a thread of continuity and identity.

Let's look at Layer: actual graphic elements may be included in a Layer. I therefore suppose that a Layer has an identity: if you change the name of a Layer, like in Photoshop®, all the objects that were in that layer are still there, in the renamed layer. Conclusion: Layer is an entity.

Now, can the Layer stand on its own ? Well, the layer is not dependent on the objects contained therein. However, in your example, would the layer be something that is completely independent that exists across all the graphics that your software manipulates ? Or is the layer something that only exists within the specific graphic in which it was created ? Otherwise said, when you start a new graphic, are the layers already there, and shared with other graphics, or do you start with a new default layer ? I'd think it's certainly the second case: so Layer is owned by Graphic.

AGGREGATE: A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the AGGREGATE, designated as the root. A set of consistency rules applies within the AGGREGATE’S boundaries.

So in your model, Graphic would certainly be the aggregate root, and Layer would be an entity in that aggregate.

Finally, the bounded context would be your domain for a graphics editing. In your model this would certainly remain the sole bounded context, unless you'd extend the model, with a relatively independent domain for 3D motion capture, which would not rely on the graphics model and thus stand on its own.

Answer 2

The definition of Bounded Context is not fuzzy at all and it is extremely helpful. This is the essence of DDD and until you get the idea, you probably will struggle to understand the value of this approach.

One of the definitions of Domain-Driven Design is:

Developing Ubiquitous Language within Bounded Context

The Bounded Context is where terminology of your language have the same meaning. Classic example is the concept of Product in eCommerce, which can be: - Description and photo in the Product Catalog context - Weight, size and packaging details in Delivery context - Price in Pricing or Sales context - Stock level in Warehouse Management context

Each of those context needs to have a separate view on the same physical object, which is limited by explicit interest of that context. The main idea is your system cannot have a holistic model, instead it consists of multiple models, which concentrate on representing their own view on real world.

Bounded Context allows you to split your system to individual, autonomous components. You can assign different teams to work on different contexts. You can build services aligned with context boundaries. It actually becomes obvious what DDD is all about.