Question

Well this time the question I have in mind is what should be the necessary level of abstraction required to construct an Aggregate.

e.g.
Order is composed on OrderWorkflowHistory, Comments

Do I go with
Order <>- OrderWorkflowHistory <>- WorkflowActivity
Order <>- CommentHistory <>- Comment
OR
Order <>- WorkflowActivity
Order <>- Comment

Where OrderWorkflowHistory is just an object which will encapsulate all the workflow activities that took place. It maintains a list. Order simply delegates the job of maintaining th list of activities to this object.

CommentHistory is similarly a wrapper around (list) comments appended by users.

When it comes to database, ultimately the Order gets written to ORDER table and the list of workflow activities gets written to WORKFLOW_ACTIVITY table. The OrderWorkflowHistory has no importance when it comes to persistence.

From DDD perspective which would be most optimal. Please share your experiences !!

Answer 1

As you describe it, the containers (OrderWorkflowHistory, CommentHistory) don’t seem to encapsulate much behaviour. On that basis I’d vote to omit them and manage the lists directly in Order.

One caveat. You may find increasing amounts of behaviour required of the list (e.g. sophisticated searches). If that occurs it may make sense to introduce one/both containers to encapulate that logic and stop Order becoming bloated.

I’d likely start with the simple solution (no containers) and only introduce them if justified as above. As long as external clients make all calls through Order‘s interface you can refactor Order internally without impacting the clients.

hth.