Last active
November 23, 2016 21:33
-
-
Save SelrahcD/d56f19bd832060dedad29a6ba3b842b1 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Time sheet system | |
| In my opinion we have two options : | |
| 1) The notion of time sheet is only a view concept (I want to see all entries of week #10) : | |
| * a TrackTime command that only creates a new entry in a list and takes the (time; imputation) as parameters | |
| * TimeSheet is a projection of the entries, here probably a subset of the list entries | |
| 2) The notion of time sheet is important in domain (I don't have an example...) : | |
| * a TrackTime command that adds an entry for that specific time sheet and takes (timesheetId; time; imputation) as parameters | |
| * TimeSheet can possibly be used in the read model too. (Lot of ifs here) | |
| For both cases if an entry had to be modified I'd go with a CorrectTimeEntry(timeEntryId, correctedTime) command. |
Since I can't upvote on gists and we don't get any notifications I moved the discussion to the PHPDDD project:
See you there!?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've been thinking about it since I wrote it and clarifying what a TimeSheet is would help for the conversation.
As I see it (from my past experiences with time tracking software) it's a recap of time entries during a week. We have two notions : opening a new TimeSheet and tracking a new entries. And then separated commands : OpenTimeSheet (could be triggered by a CRON, a create cmd), TrackTime (a create cmd), CorrectTimeEntry (an update cmd - would be a create command too if doing event sourced).
The draft example is a good one. I've been working with this concept a few days recently and we had several notions :
We used two different commands for StartDraft and UpdateDraft. Some of the code looked a lot the same (we had only a few fields so it wasn't really an issue). If the number of fields had grown we probably would have introduced some sort of service playing with command data to populate all the fields. Looks like a lot of setters would be needed though, which points out we're getting closer to something CRUDy. I guess a service and an abstract command are quite the same in the end, so yes, an abstract command would work. I won't use the same command yet and keep the two "real" commands separated.
I suppose using an abstract command for similar commands is ok for exceptional cases but if it's the norm of the system a CRUD app would probably have done the job perfectly.