It reminds me of the conversation you and and I had on the way to the MS campus back in March. One point that really sticks out for me is this:

“All of these items are required to represent the real-world customer given my architecture.”

To me this is huge! It’s context, context, context! Sometimes I think we get too involved in the “right & wrong” arguments of development and stop focusing on the core of application (what does it need to do and for who?).

We all just need to remember that OO at its core is the passing of messages to objects (yes, objects not classes) and that’s it. The fact that you have encapsulation, inheritance, blah, blah…that’s just icing on the cake.

I generally don’t use standalone factory classes. Instead, I like a mix-up of the old skool GoF builder pattern but external. I’ve called them in the past a build-to-order specification, but I think it’s really a GoF builder. I’ll feed a builder into a Factory Method living on a repository. I try to keep aggregate roots in control of creating it’s entities in a Demeter-safe (which I wholeheartedly believe in as a core design tenant (excepting method chains)) fashion.

You can have one or more Builders that deal with the invariants and at that point you can persist the class. I like Jimmy Nilsson’s idea of a least-restrictive sense of persistance. That is, I think it’s cool to go ahead and persist entities that are broken. I’ll just persist the reasons they are broken.

Yes, no, maybe, ha ha?

Anyone care to weigh in on Factories from DDD? Where does your Customer start its life (ie..before it was persisted the first time)?

I’m coming to think of DTOs as pretty much messages. I’m just reading Gregor Hohpe and Bobby Wolfe magnum opus on Enterprise Integration Patterns and digging back through Udi’s blog. Recently I’ve been mostly in application stacks so I try to keep it simple. Still, I’m a big fan of a “service membrane.” I find by making it part of the default architecture, seperating out contracts (interfaces and DTOs) into a module that clients (UI, integration services) take dependency on _greatly_ contributes to partitioning and maintainability.

Even w/ the slice approach it’s not too thin a slice. Sometimes you find occasion to use make two DTOs fill in for one purpose. I think (keyword) that I’ll probably come around to the idea of each operation having a _distinct message_ (request, response, both, none) and DTOs are more the elements used to compose these message. So like in XSD parlance DTO as complex type. Message as root element.

How many classes does it take?

* ignoring proper design principles… one!
* one might argue also….. no more than is absolutely needed. Resist the urge to put in tons of flexibility where it is not warranted
* and, like you say, to accurately represent a real-world object you’d need a plethora of classes that model even the tiniest behavior.

Interesting note on the sidebar… I like your take on just giving certain screens the “slice” of data that they need and nothing else. That frees you to model your domain independently of the specific UIs as long as you keep up the translation. I’m curious how you manage to have many different “flavors” of DTO, depending on the consumer… perhaps another blog post?