Domain Driven Design and CAB

Topics: CAB & Smart Client Software Factory
Dec 2, 2007 at 10:01 AM
My team is small and has decided not to use client-side Mocks and client-side Unit tests. Since this is one of the primary reasons for using Presenters (MVP), I've been kicking around the idea of replacing Presenters with Domain Entities using Domain Driven Design. DDD appears to fit nicely with the concepts in CAB:

http://en.wikipedia.org/wiki/Domain-driven_design
http://www.infoq.com/presentations/strategic-design-evans
http://jimmynilsson.com/blog/

For one, in my humble opinion, since I'm not using Mocks, the several Presenters (and Interfaces) now "clutter up" my Module's WorkItem and View folders in my Solution. Whereas Domain Entities can be placed in a separate project of their own.

Secondly, and more importantly, I realize that I have code buried in my Presenters that is specific to Business Domains and potentially re-usable across Modules. In particular, my web service proxy calls for a particular Business Domain live in Presenters, so if I am in a single Module, multiple views can re-use that same Presenter, but if I want cross-module access to that code, I am somewhat out-of-luck. Especially if that WorkItem or Module is not loaded. What if I want access to that Presenter code without needing or wanting a related view? It doesn't make much sense to new up a Presenter from another module just to access its code? Whereas, I believe it makes perfect sense to new up Domain Entities across an entire CAB solution.

My vision is that from any Module, I will be able to new up a Domain Entity, such as a DomainDeal (which wraps a lightweight Deal Business Entity along with a reference to a WebServiceProxy-wrapper Service) and call the following code:
DomainDeal.Retrieve(guid) or DomainDeal.Save()

Previously, this code lived in my View as:
_presenter.RetrieveDeal(guid) or _presenter.SaveDeal()

I know I'll be breaking the SingleResponsibility rule by using Domain Entities in this way. Others will likely argue to use a separate Repository class to do this:
DomainDeal d=DealRepository.Retrieve(guid)

However, I will pull my "matter of taste" or preference card here . . . my DomainEntities are a bit like Presentation Entities in the way I'm using them.

Let me know if anyone else finds this DDD approach intriguing for use in CAB . . . I believe that it dovetails nicely.

Cheers,
Bryan