Timeline for Modeling invariants that requires data from multiple aggregates
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 9 at 2:21 | vote | accept | F21 | ||
| Apr 13 at 12:41 | comment | added | Filip Milovanović | (by functions or classes), but may exist, say, as comments explaining what various blocks of code are for. A thick (rich) model is when you find a way to pull out that high-level logic and place it into the "core" together with the data model - either in an OO style (behaviors bundled with data), or in some other style (it doesn't really matter). It’s not about making the core capable of executing the entire process by itself (you have to "plug in" all the surrounding infrastructure for something to actually happen - but that also allows you to try plugging in different things). 3/3 | |
| Apr 13 at 12:41 | comment | added | Filip Milovanović |
the logic is in the surrounding service code - but that’s kind of a bad way of explaining it, cause that’s not really what the issue is. After all, is there a fundamental difference between object.DoThing(params) and DoThing(object, params) (which is what’s going on under the hood anyway)? In a thin (anemic) model, the high-level logic is intermingled with operational concerns (like how and where you fetch the data from, what specific APIs you're calling, where you save it, things like that). In this scenario, a lot of the high-level logic might not be explicitly represented ... 2/3
|
|
| Apr 13 at 12:40 | comment | added | Filip Milovanović | @Basilevs If you mean the Fowler pattern, I wouldn’t say it’s incompatible, cause it’s already half-way there - the details are internal to the class, so whatever is using it doesn’t know about them. You can start with an Active Object, then evolve it over time - what Fowler calls "finder" methods can be extracted into a Data Mapper (which is a Repository in DDD terms), and then you're free(er) to tweak and refine the Active Object as a domain model element. And DDD does advocate for a thick domain model. People tend to say that a thin model is when your objects contain no behavior, and 1/3 | |
| Apr 12 at 13:02 | comment | added | Ewan | It would be odd to see. But I don't think there is an issue with "removing from the set of things that exist", it's just, do you have a domain object which is "the set of all things"? normally not | |
| Apr 11 at 20:52 | comment | added | Basilevs | I guess a better, more specific question would be - can Active Record be compatible with DDD at all? | |
| Apr 11 at 20:50 | comment | added | Basilevs | So my Active Record implementation of an aggregate root, is not a part of core domain? This implies thin model, and I thought DDD is about thick models. | |
| Apr 11 at 20:36 | comment | added | Filip Milovanović | (In the sense of how many rules they impose on you.) Ignoring the underlying technical reality was never the idea - it will always have some amount of influence on your modeling choices, it's just that you want to keep the specific of how it's done separate from the code in the core domain. Also, on some projects, the team might have the freedom to choose the set of technical capabilities and constraints that they feel better suits the project (e.g. by choosing a graph database, rather than a relational one), so that might give you a bit more freedom. 2/2 | |
| Apr 11 at 20:36 | comment | added | Filip Milovanović | @Basilevs - The idea is to design aggregates so that they reflect the domain, and support the usage patterns in that domain (like, taking into consideration what commonly needs concurrent access by users, what doesn't, etc). You might need to collect data on that first (say by leveraging domain expert experience, or by running some initial version of the system in production). But of course, you cannot completely ignore technical constraints, for performance or other reasons. And you might have more or less freedom there depending on how picky the frameworks you are using are. 1/2 | |
| Apr 11 at 14:17 | comment | added | Basilevs | Noob question: can aggregate roots be designed with technical considerations in mind? Should not they be domain specific instead? | |
| Apr 11 at 9:59 | history | answered | Ewan | CC BY-SA 4.0 |