How to go about creating an Aggregate

开发者_运维技巧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 !!

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.

This is a good question, how to model and enrich your domain. But sooo hard to answer since it vary so much for different domain. My experince has been that when I started with DDD I ended up with a lots of repositories and a few Value Objects. I reread some books and looked into several DDD code examples with an open mind (there are so many different ways you can implement DDD. Not all of them suits your current project scenario). I started to try to have in mind that "more value objects, more value objects, more value objects". Why? Well Value objects brings less tight dependencies, and more behaviour. In your example above with one to many (1-n) relationship I have solved 1-n rel. in different ways depending on my use cases uses the domain.

(1)Sometimes I create a wrapper class (like your OrderWorkflowHistory) that is a value object. The whole list of child objects is set when object is created. This scenario is good when you have a set of child objects that must be set during one request. For example a Qeustion Weights on a Questionaire form. Then all questions should get their question weight through a method Questionaire.ApplyTuning(QuestionaireTuning) where QuestionaireTuning is like your OrderWorkflowHistory, a wrapper around a List. This add a lot to the domain: a) The Questionaire will never get in a invalid state. Once we apply tuning we do it against all questions in questionaire. b) The QuestionaireTuning can provide good access/search methods to retrieve a weight for a specific question or to calculate average weight score... etc.

(2)Another approach has been to have the 1-n wrapper class not being a Value object. This approach suits more if you want to add a child object now and then. The parent cannot be in a invalid state because of x numbers of child objects. This typical wrapper class has Add(Child...) method and several search/contains/exists/check methods.

(3)The third approach is just having the IList exposed as a readonly collection. You can add some search functionality with Extension methods (new in .Net 3.0) but I think it's a design smell. Better to incapsulate the provided list access methods through a list-wrapper class.

Look at http://dddsamplenet.codeplex.com/ for some example of approach one.

I believe the entire discussion with modeling Value objects, entities and who is responsible for what behaviour is the most centric in DDD. Please share your thoughts around this topic...