Timeline for Repository interfaces returning DTO in clean architecture used by query handlers
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 26 at 20:31 | comment | added | Filip Milovanović | So, it's not that there's some class that is designated a "domain model" and then you sometimes need to return "a subset of a domain model’s properties"; instead, if it's a legit use case, such a subset and the logic surrounding it is in some way represented within the the domain model (in this broader sense), it is a part of it (maybe it's a separate class, or a narrower interface, or maybe a part that you also reuse to compose the full object - how exactly is up to you and your understanding of the problem domain). Otherwise your domain model is not representative of your problem domain. 2/2 | |
| Feb 26 at 20:31 | comment | added | Filip Milovanović | @MrChudz "Often, we need to return only a subset of a domain model’s properties" - I know people call these entities "models", but that's a slight misuse of the term, and is now causing some confusion, because it's not what we're talking about when we say "domain model". It's not a particular class: it's the set of all the classes + the associated high level logic that forms the core of your domain layer and captures the essential aspects of the problem the application is tackling (meaning it is an effective in-code representation of it, supporting the needs of the application). 1/2 | |
| Feb 26 at 18:21 | comment | added | Greg Burghardt | @MrChudz: you aren't talking about a DTO then. You might be interested in Repository returning multiple aggregates and What's the point of "use case optimal query" and partial aggregates in DDD?. Your question doesn't mention anything about DTOs, nor does it mention anything about partial domain models, customers and orders. If that's what you are asking about, please ask another question with more specific info. | |
| Feb 26 at 18:10 | comment | added | MrChudz | You are talking about an ideal world where domain models are sufficient and DTOs are unnecessary—but such worlds don’t exist. Often, we need to return only a subset of a domain model’s properties, and you haven’t provided any reasonable solution for that. | |
| Feb 26 at 12:40 | comment | added | Greg Burghardt | @MrChudz, it might be worth considering how useful all these DTOs are. Too many times I see teams return DTOs at every juncture in their application. It becomes a misapplied pattern. DTOs are meant to be serialized to and from a string. They aren't supposed to be a general purpose property bag. At some point all those DTOs become an anemic domain model layered on top of your rich domain model. | |
| Feb 26 at 5:28 | comment | added | MrChudz | Can I have separate read-only repositories that return DTOs, with their interfaces placed in the Application layer? | |
| Feb 25 at 23:06 | comment | added | Flater | @MrChudz: You'll find that software architectures tend not to be formulated with bespoke query optimization in mind, by nature of it being bespoke. The core goal of domain-centric architectures is that the domain prescribes the internal model being passed around the application (until it gets mapped to a public-facing DTO). If you feel that this domain model does not fit your use case and wish to solve it another way, that means you're leaving the domain-centric path. That can be justifiable, but then you can no longer rely on your domain-centric guideline to tell you how to do it. | |
| Feb 25 at 21:01 | comment | added | Filip Milovanović | @MrChudz - if I understood you correctly, your comment suggests that your domain objects closely mirror the database tables, while your DTOs are more in line with the use cases of your application (which ideally should be what the domain objects are doing). This design is what makes translating the queries unwieldy and far from optimal. I think this is also what Basilevs was getting at. | |
| Feb 25 at 20:26 | comment | added | Basilevs | @MrChudz not if customer name is a domain object | |
| Feb 25 at 19:05 | comment | added | MrChudz | I need only the customer's first and last name and the total number of their orders over $100. This would result in two queries and redundant data being returned, which is unacceptable. | |
| Feb 25 at 18:35 | history | edited | Greg Burghardt | CC BY-SA 4.0 | added 143 characters in body |
| Feb 25 at 18:08 | history | answered | Greg Burghardt | CC BY-SA 4.0 |