Timeline for Can a Domain Service Also Be a Factory?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 30, 2018 at 23:55 | vote | accept | Todd Skelton | ||
| Mar 30, 2018 at 23:53 | comment | added | user3347715 |
Okay, so in this case I think my above example would be sufficient as the event applies to some action on the account, rather than the infrastructure retrieving and reconstituting the account. I would recommend, rather than adding logic to getters, separating the data into a single Value Object and restricting access to just one method. The key here is to "program" the logic into your system such that even a misguided developer couldn't accidentally expose data somewhere without invoking the domain method.
|
|
| Mar 30, 2018 at 23:49 | comment | added | Todd Skelton |
I'm just trying to figure out the best place for this logic, where it won't be bypassed accidentally. With the open() method, I could throw exceptions on all the getters if the state isn't "opened" but that seems rather smelly.
|
|
| Mar 30, 2018 at 23:45 | comment | added | Todd Skelton | The dispatcher will look for all event handlers and execute the handle method on each. Event handlers could really do anything with the event. Send an email notifying the account has been opened. Create an entry in an access log. Start a time tracking event then ends when the user leaves the record. Events will not be raised on search results, only when a record is clicked on. | |
| Mar 30, 2018 at 23:41 | comment | added | user3347715 | @ToddSkelton If you made a search-results page that listed several accounts, would you need to raise this event on every account returned? Or just the one the user decided to click on? Just spit-balling here... getting those DDD juices flowing | |
| Mar 30, 2018 at 23:36 | comment | added | user3347715 | @ToddSkelton ... If this rule doesn't truly apply to the low-level process of the actual retrieval, but rather, the higher-level process of users viewing information, you could make it impossible to view the data associated with an account unless it's in the "open" state. How is this event processed? What happens after dispatch? | |
| Mar 30, 2018 at 23:33 | comment | added | user3347715 | @ToddSkelton Define "queried". It seems unlikely to me that a user would even know what that means. What I am trying to do here is parse out if there exists a difference between physically "retrieving" an account from the disk, or going a step further and also "viewing" that account. Does this rule apply to you/other developers when you are testing (I'd assume at some point you will/have retrieved accounts from the disk)? Do you see what I am saying here? Normally, I would say that the retrieval of data is outside of your domain. It doesn't know or care about how it retrieved or persisted... | |
| Mar 30, 2018 at 23:17 | comment | added | Todd Skelton |
The eventing is pretty much the entire reason for having this service. Most events are contained in the AdministrationAccount but I need I way to track when the accounts are pulled (queried) by another user. It's hard to force an event on retrieval of an object without using the service that retrieves it. I see where you are going with the Open() method, but where would I call this, so it wouldn't be bypassed?
|
|
| Mar 30, 2018 at 23:00 | history | answered | user3347715 | CC BY-SA 3.0 |