Timeline for Is an event based approach the right way to think about this problem?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 2, 2017 at 14:45 | comment | added | Doc Brown | @user1620696: see my answer. | |
| Jul 2, 2017 at 14:32 | comment | added | Ewan | well my suggestion is the employee simply log employeeId, abc, 8 hours, date 01/01/2001, projectId xyz. yes its not what the requirement states exactly. But it has the advantage of working in practice | |
| Jul 2, 2017 at 14:24 | comment | added | user1620696 | I agree with logging these tuples. Actualy, I had imagined the event classes with this structure: a reference to the employee, to the project, the datetime when the event happened. I've imagined two classes, one for start and one for ending. When the employee starts a tuple is recorded and another when he finishes. Anyway, the customer says he wants the employee to "inform when he starts working" and "inform when he finishes what he had started". If I just code a feature that allows him to inform start and end times into the project, I'll be implementing something else, won't I? | |
| Jul 2, 2017 at 12:44 | comment | added | Ewan | well. we do know the requirement stated in the question. | |
| Jul 2, 2017 at 12:33 | comment | added | John Kouraklis | Ewan, I agree with your point and I think the approach you propose (employees to log times) is more efficient. Of course, we don't know from the requirements whether the project has start and end time/dates or duration | |
| Jul 2, 2017 at 11:45 | comment | added | Ewan | sure but you are working on the same underlying data, hours or start/stop events. in my experience entering the events in enough detail to produce the report correctly is hard for the reasons I outline. I would question whether that model really matches the business requirement. ie, surely a client pays for dev hours assigned to the project. a somewhat abstract concept which you don't want to reduce if a meeting overruns | |
| Jul 2, 2017 at 11:18 | comment | added | John Kouraklis | Ewan, I think the reporting itself has to be a separate entity (class or classes) in order to honor separation of concerns and SOLID principals. The project/time logger entities should not deal with reporting | |
| Jul 2, 2017 at 11:15 | comment | added | John Kouraklis | Technically, when you log your first date/time you start the work on this project unless one can "start" working on the project but "put real work" later. This is not clear from the requirement. | |
| Jul 2, 2017 at 7:55 | comment | added | Doc Brown | Ewan, you 100% right, the logged start and stop times may be interpreted as events itself, which just supports my point: the OP first needs to focus on logging the tuples (employer, project, time, [start|stop]), indepently from the idea of using events, or if these tiples are already the events, or if "event" is just a buzzword they don't need. | |
| Jul 2, 2017 at 7:35 | comment | added | Ewan | well if you log X hours and provide a start date, then you have techincaly provided start and end events. However, I would concentrate on the "So that.." part of the requirement. Can the chosen method produce those reports? if not you have to go back to the business | |
| Jul 2, 2017 at 7:23 | comment | added | Doc Brown | I would say the OP needs a way "having employees log hours against a project" independently from the decision for or against events. | |
| Jul 1, 2017 at 21:22 | history | edited | Ewan | CC BY-SA 3.0 | added 7 characters in body; added 1 character in body; deleted 4 characters in body |
| Jul 1, 2017 at 21:16 | history | answered | Ewan | CC BY-SA 3.0 |