Geeks With Blogs
Mike Nichols - SonOfNun Technology If I were the captain on a big steamboat...

Continuing with tightening my app using Domain Driven Design principles, I am trying to instantiate a NEW Person object.

SETUP:This Person object has Email objects (whether Value or Entity is irrelevant). Now, the Person is my Aggregate so a PersonFactory class exists. Person has a method 'AddEmail(string text, string label, bool isPrimary)' .

PROBLEM: I have a Service Layer (application layer) that is operating on my use case 'Add Person' and my view has created a PersonDTO that has a collection of EmailDTO's.

So from within your PersonService.AddPerson(PersonDTO personDTO) method, do you just pass thru the DTO to a PersonFactory and have the Factory iterate the DTO's collection for adding emails, or do you pass only primitive types to your factory to get a fresh person WITHOUT emails added and then add the emails from outside. Seems like that violates the notion of the Factory guarding the instantiation of Aggregates and its invariants (child objects).

The notion of refactoring large parameter lists into a Parameter Object [Fowler Refactoring] seems just alot like a DTO...I realize sometimes DTO's aren't simply dumb data containers in a 1 to 1 relationship with Domain Entities, but if I have EmailDTO that has the same parameters as a EmailParameterObject would have, I don't see why I need yet ANOTHER dumb object to pass around.

I am fuzzy on the notion of Factories managing the new instantiation of ALL invariants of Aggregates. This would seem to necessitate either long parameter lists, or maybe Parameter Object's...which look just like DTO's to me.

Any thoughts? Posted on Friday, August 18, 2006 5:31 AM OOP, Patterns, Architecture , Domain Driven Design (DDD) | Back to top


Comments on this post: A Data Transfer Object is a Parameter Object for my Factory?

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Mike Nichols | Powered by: GeeksWithBlogs.net