Timeline for Using external services in domain driven design
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 12, 2019 at 20:12 | comment | added | inf3rno | @RikD I asked a new question for that: softwareengineering.stackexchange.com/questions/402431/… | |
| Dec 12, 2019 at 12:47 | comment | added | Rik D | Instead of grid.moveUser(userId, position) you could probably encapsulate the grid within the user, so the call becomes user.moveTo(position) | |
| Dec 12, 2019 at 10:47 | comment | added | inf3rno | I found here meanwhile that there can be "impure domain services". enterprisecraftsmanship.com/posts/… The actual article is not about that though. I need to read more from that site, but it is definitely interesting. | |
| Dec 12, 2019 at 10:45 | comment | added | inf3rno |
Yes, those are just the first examples. When I don't know what to do with a feature I use to move it into a service and later when I found the right object I move it there. Yes, I agree that it is really anemic domain that way, that's why I want to have something better. For example grid.moveUser(userId, position) no longer looks like data retrieving. So I guess I found the proper domain object for that method. I am just not sure if the grid should be aggregate root here, but that is a different question.
|
|
| Dec 12, 2019 at 10:37 | comment | added | Robert Bräutigam |
Sure, and that is what I'm arguing for. If you already do that, that's great. I'll note however, that TimeService or ProbabilityService are not part of the domain, User and Grid are. Services are not derived from the "Ubiquitous Language", they are technical. I only mention the "data" aspect, because there are only 2 methods on "domain" objects in your examples, those are: getDate() and getPosition(). Both are suspiciously data-oriented.
|
|
| Dec 12, 2019 at 10:30 | comment | added | inf3rno |
"essentially just data, without any functionality" - why do you think a pure model is just data? In the case of my second example I can add an algorithm that finds the nearest point to the user's position on the grid and gives the probability of that point. But I can average the probability of the nearest 4 points, etc. All of that can be part of the domain. In the first example the clock.sameDayAs(startTime) && clock.after(...5am...) condition can be part of the domain. None of that is just pure data.
|
|
| Dec 12, 2019 at 9:26 | comment | added | Robert Bräutigam | I am aware that there are a lot of articles and even books out there that want the "model" to be "pure" in the sense that it is essentially just data, without any functionality. Maybe that is also what you want. I'm merely pointing out, this is not the only option, and probably not the best option. Most articles and books on object-orientation should be a good reference why this is not a good path to take. OO-DDD, Object Thinking | |
| Dec 12, 2019 at 9:11 | comment | added | inf3rno | "It seems there is a fundamental assumption in your solutions that there can be no external dependencies in the "domain", it must be completely "pure". This is neither true nor practical." - Can you send a reference? I mean I read a few times that the model should not include external things, because calling an external service can result in errors and error handling would make the model complicated. In both cases it is possible to workaround this by updating something inside the domain using a loop and that loop calls the external service from outside the domain. | |
| Dec 12, 2019 at 9:08 | comment | added | inf3rno |
As of the second example what I really need is checking the probability for the position of the user using a position->probability grid, and when it reaches a threshold, then send a notification to the user. I update the grid using an external service. I think the approach Voice suggested is better for that problem and I would go even further and include the concept of the grid as an entity in my model. Maybe I can even make it an aggregate root and do something like grid.update(dataFromExternalService) or grid.moveUser(userId, position).
|
|
| Dec 12, 2019 at 8:59 | comment | added | inf3rno |
In the first example it would be good to have a canBeCancelled method, so it won't show the cancel button to the user if the appointment cannot be cancelled, but it really depends on whether we want to do CQRS or this code will used both for read and write.
|
|
| Dec 12, 2019 at 8:39 | history | answered | Robert Bräutigam | CC BY-SA 4.0 |