New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try to break the whole RD diagram with yet another new object model #84

Open
wingsofovnia opened this Issue Jan 25, 2017 · 10 comments

Comments

Projects
None yet
4 participants
@wingsofovnia
Copy link
Collaborator

wingsofovnia commented Jan 25, 2017

No description provided.

@wingsofovnia wingsofovnia self-assigned this Jan 25, 2017

@wingsofovnia

This comment has been minimized.

Copy link
Collaborator Author

wingsofovnia commented Jan 26, 2017

Domain Driven Class Diagram

cd-ddd-friendly-plans

cd-ddd-friendly-plans.xml.zip (draw.io)

@mikolevy

This comment has been minimized.

Copy link
Collaborator

mikolevy commented Jan 27, 2017

I think there is two parts of that subject:

  1. Non Event-model concept
    From what I understand it's almost at all compatible with our current concept, yes? Because we're using ORM, our low level model have to be expressed with details suitable for ORM convention, but - as I understand this Class Diagram - this high level concept from the Diagram is compatible with current low level model. In other words I understand that concept of Child, Plan, Task and Step is just the same what we have implemented in ORM PR. The main differences are:
  • naming (Plan -> PlanTemplate and so on) - but it is connected with Event-model concept (point 2)
  • Connection between Child and Plan (it's connected with Event-model concept too)
    There is also one small thing, which I think isn't so important at all but in Plan there is List and there is no Break Entity at all.
  1. Event-model concept
    It's a little bit more complicated, because when we discussed it last Wednesday we forget about one future feature, which is not so important right now, but choosing event-model may have impact on it. It's about storing historical plans and activities (all task which have ever been done by child) and syncing it with external system (e.g. MROZA) - such reporting feature for therapists. Of course in every model it would be possible (probably) but in such case saving tasks and so on in separated entities may have some advantages in comparison to using one event storage.

Summarizing, I think we should move forward with current model (we already have plan model classes written in ORM convention and our project-planning phase last a little too long).

@wingsofovnia

This comment has been minimized.

Copy link
Collaborator Author

wingsofovnia commented Jan 27, 2017

@mikolevy
There is also one small thing, which I think isn't so important at all but in Plan there is List and there is no Break Entity at all.
By mistake. Link<Break> breaks should be Link<Task> breaks. **

Regarding history future feature. It's can be done easily, for example, by extracting Event entity from Plan aggregate root. An it will be the exact structure we discussed earlier. Placing the Event entity inside the Plan AR looked to be a good idea that meats all domain requirements seamlessly and simplifies orm processing.

I kindly ask you to discuss this proposition in details and do not accept a contrary solution that is heavier, complex and anemic so fast.

** fixed 27.01.2017 18:24

@wingsofovnia

This comment has been minimized.

Copy link
Collaborator Author

wingsofovnia commented Jan 27, 2017

I'll prepare new diagram today.

@Artem3

This comment has been minimized.

Copy link
Collaborator

Artem3 commented Jan 27, 2017

My 5 cents:

  1. Minor suggestion. I believe the better name for Event is Status.
    and EventType renamed to StatusDetails ??!!
  2. For sure, simplicity is good. But main criteria, as for me, is following: Are there any user scenarios which could not be implemented with New architecture ?
    @mikolevy any tricky requirements ?
@wingsofovnia

This comment has been minimized.

Copy link
Collaborator Author

wingsofovnia commented Jan 27, 2017

@mikolevy @malsolec @mgruca

2017-01-27 18 53 03

Action (Event, or @Artem3 's Status) is completely separated now so you can log any type of action and make any kind of selections your mind can imagine :)

genmymodel-friendly-plans-db.xmi.zip

@mikolevy

This comment has been minimized.

Copy link
Collaborator

mikolevy commented Jan 28, 2017

Okey - we will discuss this after the weekend

@mgruca

This comment has been minimized.

Copy link
Contributor

mgruca commented Feb 2, 2017

@mikolevy historical data is easy. Actions are a log basically, so it will tell you which child did what and when. So you have a plan, and detailed step by step information how it was executed
@wingsofovnia

  1. I miss timestamp in Action.
  2. Do we need step? Now I'm pushing us in weird direction, as self joins are not common, I do it more to have discussion about meaning of each entity. If step may be a task and task may be a step, depending on situation, then current model does not represent that, despite being simpler. Do we allow one step to be in different tasks?
  3. We miss information that task/step (?) is a break in a plan. Class wise plan could be
    class Plan {
    List tasks;
    Set<Task/Steps> breaks;
    }
@wingsofovnia

This comment has been minimized.

Copy link
Collaborator Author

wingsofovnia commented Feb 2, 2017

@mgruca

  1. yep, missed that
  2. well, that's a good point. these tables look almost identical. nevertheless, it's a matter of our understanding of the domain context and i think it's a good question for @mikolevy.
  3. missed that. I'll add tables for such relations.
@wingsofovnia

This comment has been minimized.

Copy link
Collaborator Author

wingsofovnia commented Feb 6, 2017

2017-02-06 21 18 32

  • Add event timestamp
  • Add plan -> Task/Break relation tables

malsolec added a commit that referenced this issue Apr 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment