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?