My company has an application that allows users to perform a diagnostic medical test that measures circulating blood volume. This test involves using a gamma counter to measure/count the radiation in multiple blood samples. These samples are placed in a motorized carousel (i.e., sample changer) that moves the samples over the gamma counter to be counted.
Here’s what we believe our domain nouns are:
- Test (i.e., blood volume, quality control)
- Patient
- Sample (i.e., something to be counted)
- Spectrum
- Test execution context (i.e., specification of the samples and their order that correspond to a certain type of test)
We believe our domain verbs are:
- Moving the carousel to a given position
- Obtaining a spectrum (i.e., counting a sample)
- Running tests
As we understand domain driven design, the business logic should go in the domain. Our business logic resides mainly with what we’re calling a test execution controller. This controller uses a test execution context to determine how to move the samples into position and to have the gamma counter measure them.
The specific technologies that are giving us some confusion are Prism and WCF.
(1) Prism relies on an event aggregator to pass non-CLR events around the system. The test execution controller uses this to let other parts of the system know what’s going on (e.g., Sample 2A is being counted, there are 34 minutes remaining for the current test). Technically, the event aggregator is a technology that’s part of Prism, and domain objects/services are not supposed to rely on technology.
Question: Is there a way to restructure things so that our domain service isn’t technology-dependent?
(2) We have two WCF services that allow us to communicate with the sample changer and gamma counter. Each service has a contract (i.e., an interface that’s decorated with WCF-specific attributes). At least with the contracts, we separate the concerns such that our main application depends on behavior, rather than a specific sample changer or gamma counter. However, WCF is a technology and the application code needs to know that this service we’re talking to is a WCF service (which is done by creating a proxy class). To satisfy DDD constraints, we end up having several similarly named classes/interfaces that seem redundant. Here’s an example
- IGammaCounterService – WCF contract that defines methods to communicate with a gamma counter. This interface is referenced by (1) the WCF side of things where the actual implementation lives, and (2) application code that talks to this service.
- IGammaCounter – set of properties/methods that defines the behavior for a gamma counter. (This is part of our domain.)
- GammaCounterProxy – class that implements the WCF service contract. This is what our application uses to communicate with the WCF service.
- GammaCounter – class that is used by the business logic. This is a GammaCounterProxy (via inheritance) and also implements IGammaCounter. (Note: We use an inversion of control container – specifically Unity – to register this instance within our application.)
Question: We have interfaces in the domain and on the WCF side that basically have the same method names. Is there a better/cleaner way to do this?
An additional axis of structure to consider within a solution is the set of application layers. For example, it appears that in this case you have a presentation layer (implemented using Prism/WPF), a service layer (implemented by WCF) and a business/domain layer (implemented using DDD).
If the test execution controller is a controller in the MVC sense, then it should not contain business logic. Instead, its job is to coordinate interactions between the UI and the business layer. In this particular case, the controller should forward commands to the business layer through a WCF implemented service layer. However, the controller itself is part of the presentation layer and so the fact that it depends on a technology specific component such as the event aggregator isn’t a problem since you’ve already chosen WCF/Prim as the technology for the presentation layer – there is no point to abstract it, especially prematurely.
Normally this type of dual-class hierarchy results when a DDD business layer is exposed as a service via WCF because you create DTOs (data contracts) which map to domain entities and values. The DTOs don’t have behavior, their central role is to represent data coming in and out of a service. Many times a DTO will look very similar to the corresponding domain object and it is acceptable to have this duplication. If this is still a concern you can look into a mapping library such as AutoMapper.
As far as organizing the solutions you have a few options. One is to hide the domain layer completely from the presentation layer and only allow access to it through the service layer. So the presentation layer project (WPF/Prism) would reference a thin project which contains the service contract and the associated data contracts (DTOs). This can be a small project which defines the “schema” of your service layer. This project would also be referenced by the WCF project which implements the service contract. The benefit of this approach is that the domain is entirely encapsulated by the service layer. You can change the implementation of the service contract by re-deploying your service – no need to redeploy the presentation layer as well. The drawback is that it might be overkill or it might not be appropriate for the domain to be exposed as a service.
Also, I’m a little confused by your naming conventions and structure. For example, GammaCounterProxy isn’t a proxy, the proxy is generated by WCF when you get a reference to the service contract IGammaCounterService. The service implementing class itself is just an implementation, not a proxy. Also, it seems wrong for GammaCounter to inherit from GammaCounterProxy. It would make more sense for GammaCounter to implement IGammaCounter directly, and have that object be used by GammaCounterProxy (renamed to something like GammaCounterImpl). The job of GammaCounterImpl is to process some command (represented by the DTO parameters). It would do that by loading all appropriate domain objects, such as GammaCounter, invoking methods on them, and then possibly returning a result (as a DTO) which would then be processed by the presentation layer.