*Nov 2023* What if problem lies in looking at the domain model _in terms of nouns_ and requiring _unnecessary information when making decisions_? - Alberto Brandolini made [this lightning talk](https://www.youtube.com/watch?v=gU-p90-EYSY) and this recap of [100'000 stickies later](https://youtu.be/fGm62ra_mQ8?si=RcA_b99vgXcm1e-d&t=1737) and [50'000 stickies later](https://www.youtube.com/watch?v=NGXl1D-KwRI) and I also looked into the take away we got from the eventstorming workshop - Alberto disrupts the notion of aggregates, keeping the name only for historical reasons. This is in line with [Eric Evan's recent keynote](https://www.youtube.com/watch?v=R2IAgnpkBck&t=415s) about evolution of DomainDrivenDesign, and that we should not focus on tactics (such as aggregates) but rather on the key points of DDD. - **What if we postpone naming an aggregate and instead focus on the commands/actions it should support and the name will come out of it?** - Also, each command needs only some data to make a decision (ReadModel), **it probably doesn't need the whole entity (!!)** This is BIG BIG BIG!!!! - What if this is it? What if this is how to actually do design? with heavy focus on read-models, we are making it explicit on the exact minimal requirements we need, and **we don't care where that information come from**. Could be a bloated Kafka event, but it only needs to contain what we are interested in. **that ReadModel piece and that focus on commands is crucial!!** ![[Pasted image 20250214111247.png]] ![[Pasted image 20250214111239.png]] ![[CleanShot 2025-02-14 at 11.11.53 1.png]]![[Pasted image 20250214111316.png]]