Timeline for DDD referencing child of aggregate root?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 22, 2020 at 17:48 | comment | added | user3347715 | @FilipMilovanović Your example answer above is great! It points out, correctly, that an aggregate should be a consistency boundary, not just the top of some tree (and you didn't need any information about the architecture to spot that!) | |
| May 22, 2020 at 17:48 | comment | added | user3347715 | @FilipMilovanović In fact, I would go so far as to say that it would be a good thing for the poster to ignore many of these concerns to the point that they start becoming a problem. One of the best ways to learn something is to screw it all up so you truly understand the costs. I could be wrong! This could be a project intended for commercial use - where many of the questions you asked above are relevant. But I sincerely doubt it. The OP didn't ask about any of those concerns, so it's better to just leave it at that and answer the questions asked. | |
| May 22, 2020 at 17:47 | comment | added | user3347715 | @FilipMilovanović You have missed my point. I worry that the above project is never going to be more than a directory containing some files on the user's local machine. That there is never going to be a "view", or an "architecture", or even an "application". I worry that the poster is simply trying to expose themselves to domain modeling in order to grapple with design concepts. And questions that ask them to think about "data stores" and "synchronization" and "architecture" only distract from and obfuscate the problems at hand. | |
| May 5, 2020 at 17:51 | comment | added | Filip Milovanović | E.g., your Apartment class (as presented in your question) is not acting like an aggregate root - in that it's just a tree of objects, and that's not the same thing; it doesn't encapsulate what's within the aggregate, and it doesn't provide an interface to support operations on the aggregate. So it's not a DDD aggregate, even though it's designated as one, which makes other considerations superfluous, because they don't really give you any benefits if you don't have a proper aggregate root. | |
| May 5, 2020 at 17:44 | comment | added | Filip Milovanović | You don't create good aggregates by mechanistically following a set of rules - you put them into your design so that they can solve a problem for you (limit dependencies, make a group of collaborating objects cohesive, enforce invariants, enable specific usage patterns, control the complexity of storing and reconstituting objects, etc.). | |
| May 5, 2020 at 17:43 | comment | added | Filip Milovanović | "Many of the questions you are asking are not strictly relevant to provide guidance to a general modeling question like the one above" - actually, they are. (Also, I didn't expect for you to explain the entire system - they are meant to be questions that you should ask yourself when designing. Explore those topics in your domain and let what you learn guide you.) How you design your aggregates and whether or not to pursue the ideas you're currently considering depends entirely on these considerations. | |
| May 5, 2020 at 15:57 | comment | added | user3347715 | @FilipMilovanović I understand where you are coming from. I really do. But I suspect you are capable of filing in the blanks here. Many of the questions you are asking are not strictly relevant to provide guidance to a general modeling question like the one above. It is not and should not be a requirement that every poster outline their entire architecture in order to receive answers about domain modeling. Please apply the principal of charity as generously as possible when attempting to understand questions. The first 6 words of this post are "I am trying to learn DDD". | |
| May 5, 2020 at 15:49 | answer | added | user3347715 | timeline score: 3 | |
| May 5, 2020 at 2:12 | comment | added | Filip Milovanović | Well, what does "1:1" mean, in practice? What's the usage pattern? Is this the same user editing something about the Resident in one screen, that later on goes to a different view, and this view needs to reflect the change? Is it two remote users accessing different parts of the application at the same time, each with its own representation of the Resident, but the two affect each other? Must they be synchronized ASAP, or not? Are these (really or effectively) two different applications? Is there a central data store, or more then one? Model your aggregates to support the usage patterns. | |
| May 4, 2020 at 19:57 | history | asked | Marlon | CC BY-SA 4.0 |