Timeline for DDD: should entity method use repository for stored procedures (not CRUD)?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 20, 2017 at 20:56 | comment | added | Laiv | great. Thank you for remind me that repositories are still abstractions within the domain itself. | |
| Aug 20, 2017 at 20:52 | comment | added | Euphoric | @Laiv In my example, there is specific interface only for querying reservation status and only the Reservation service depends it. This makes the cut on both sides. As only code handling reservation depends on API intended only for reservations. So yes, you are correct. | |
| Aug 20, 2017 at 20:46 | comment | added | Euphoric | @Laiv This is simply question of interface segregation. In big majority of cases entity will not need access to collection of it's siblings, but I think there might be cases where, if whole entity depended on ability to query other entities or aggregate of those entities, then it is good design to give it reference to API that allows just that. Not giving it the API because of some dogmatic ideas of forbidding entities to access repositories is, I believe, wrong. | |
| Aug 20, 2017 at 20:34 | comment | added | Laiv | Ok, ok. I think I got your point now. Basically you are looking at the repository as the collection of the existing vehicles while I'm still looking at it as a DAO. But still, should a single entity to be aware of everyone else (should a vehicle to have access the collection?) I guess the answer is no, and that's why you suggested the interface segregation, in order to don't force vehicles to be aware of the collection itself. I'm right? | |
| Aug 20, 2017 at 20:27 | comment | added | Euphoric | @Laiv Can you explain what you mean by DAL? Also, do you think domain should have abstraction of "collection of all existing entities" within itself? If yes, how is this abstraction represented? If not, how would domain express behavior that works on all existing entities? And by all existing entities I mean for example "all current vehicles". | |
| Aug 20, 2017 at 20:22 | comment | added | Laiv | ok. From the unit-testing standpoint, your approach is preferable. But what's the point of allowing entities to meet the DAL? Maybe I'm too oldschool or biased by too many years abstracting the model from everything else. | |
| Aug 20, 2017 at 20:15 | comment | added | Euphoric | @Laiv The critical difference between Active Record and entity being able to access it's repository is that, with Active Record, it is not possible to structurally separate the implementation of repository (eg. the SQL commands) from the entity/record. But having a middle man, like an interface, does make that possible. So for example, unit testing of entities, in isolation from persistence technology, becomes possible. Which is, I think, main complain when using Active records. | |
| Aug 20, 2017 at 20:05 | comment | added | Laiv | would you mind to elaborate the benefits of allowing entities to meet their repositories? That reminds me to Active Record design pattern. Despite it's considered anti-pattern, I have found libs that implement it. So I'm missing the Pros. The cons I think are clear. | |
| Aug 20, 2017 at 19:02 | history | answered | Euphoric | CC BY-SA 3.0 |