I’ve been thinking about this since writing the gp comment yesterday and quite like the anchor terminology. Entity/object and “aggregate root” bring all sorts

I’ve been thinking about this since writing the gp comment yesterday and quite like the anchor terminology. Entity/object and “aggregate root” bring all sorts of complications/ambiguity. The example you gave of a non-anchor (price was it?) was helpful to clarify. Examples (and counter examples) are far easier for human brains to understand than “definitions”. so often the example domain for these sorts of exercise is “a shopping cart website” —- and I find shopping websites such a poor example, because the specifics of how the shopping experience should work at a small Website are very custom to what is being sold, to whom, and why etc. Other common domains when learning about databases — “a book lending library” (I found this a good domain when I was learning, but people’s experiences of libraries are very different now…) - a blog (posts, comments etc…) - but only fools like me write their own blog software now… (and or allow the public to comment? Yuck!) I’ve written scripts that query outlook appointments and found that their handing of recurring appointments was very odd! Writing a query that simple asks “what am I doing today?” is far from a trivial exercise, as a consequence. The choices and trade offs around storing every instance of a recurring appointment versus storing just the pattern plus the exceptions, has some pretty weird/nuanced implications. And I think the optimum approach really depends on the way I. Which the tool is used… which you don’t know until after the tool is used! (I guess that lends further proof that the most important aspect of software is that it’s open to being change in unexpected way… as any software worth writing will also need to be modified later.) Cheers! Keep doing good work!