What is the best practice for domain model re-use in composite applications?

Question

We have a composite application built using the Composite UI Application Block (CAB)/Smart Client Software Factory (SCSF). To date, each module in our composite app has used its own set of DTO's, and business logic has been duplicated throughout the module, both in the UI layer and the Service layer. I would like to pursue more Domain-Driven approach in order to encapsulate business logic in a domain layer that can be distributed to the UI tier and the Service tier, and (ideally) across modules.

We have multiple modules in our composite application under development at one time, and we need to be able to deploy them in any order. Ideally, I would like for our modules to share a common domain model, but I'm afraid that when we deploy a new version of the domain model along with a module, that we will need to regression test the other modules against the domain model.

The alternative seems to be duplicating the domain model in each module, but all that code duplication smells funny to me. Has the industry developed any best practices for this type of situation?

Answer 1

I've used a single domain model, but one which allows versioning on every individual definition. Code generation provides both the interfaces per-service, and mapping code that can cross service and version boundaries.