Domain Driven Design – [Part 2]

If you can remember from the previous post, we are trying to model a simple order/order item scenario to bring about a recent challenge I had about how to code my domain so that if external services need to be called, how do I integrate those calls/interactions with my domain.

Approach 1: Pass the interfaces into the method call.

This requires passing in the interfaces of the external services into the method call which will update the order item state.
The code for this example can be found here: ##LINK. The module is Sample1

Advantages

  1. It is very descriptive, and there’s no mistaking that the action requires external services.
  2. It’s easy to test. You could pass in mocks of the services into this method call and verify they were called as is expected.

Disadvantages

  1. Every time we introduce additional external concepts to the domain objects, we may need to add another interface to the method signature. In all fairness, we may probably have to rethink about how the model is designed, but in terms of disrupting the existing callers of this method, we’d be changing how they interact with the domain object – and should they even really care? Why shouldn’t the callers just be able to call order.placeOrder() without passing in all the interfaces needed? An example would be, what if we were to raise an event to another subsystem that needs to be notified when the customer is notified? If adopting this approach, you would need to add another interface, of re-use the existing notification service interface. However doing that would mean that the service is taking on multiple responsibilities – sending emails and raising events.
Advertisements