Shield application services from infrastructure details

57 views
Skip to first unread message

Alexandre Potvin Latreille

unread,
Sep 22, 2016, 11:47:33 AM9/22/16
to DDD/CQRS
Should we always shield application services from all infrastructure details? I'm usually not unit testing application services, but instead test them through integration tests (not sure if that is a good practice or not). Because of that, when application services have to deal with infrastructure concerns I'm always wondering if it's worth to declare an interface in the application layer (e.g. FileUploader, Logger) and implement it in the infrastructure layer or I should just use the concrete infrastructure implementations directly?

When a domain service needs to depend on infrastructure details (e.g. repository) I'm declaring an interface in the domain (with the UL in mind) and implement it in the infrastructure layer, but for services that are only used from application services I'm not sure if I should do the same?

Danil Suits

unread,
Sep 22, 2016, 12:30:22 PM9/22/16
to DDD/CQRS

Greg once observed that passing a "specification" object to a repository disguises some interface contracts that perhaps should be made explicit - the interfaces are the documentation of the environment dependencies of the model.

Does equivalent documentation of the application dependencies have value in your situation?


Alexandre Potvin Latreille

unread,
Sep 22, 2016, 1:08:25 PM9/22/16
to DDD/CQRS
I guess that making dependencies explicit has value in all layers, but certainly more in the domain and application layers.

The specific question I have is that I have a DomainEventStore interface defined in the domain (might be the source of the problem - not sure if it should be part of the domain since it's actually never used from any domain services like repositories are). I also have a `CommonDomainEventStore` implementation in the infrastructure layer. Now, I'd like to be able to provide a DomainEventMetadataProvider to the `CommonDomainEventStore`, but I'm really not sure where the `DomainEventMetadataProvider` interface should be defined.

I'd like the have an implementation of the `DomainEventMetadataProvider` live in the application layer, because this is the layer that should be responsible for auditing.

If I declare the `DomainEventMetadataProvider` interface in the infrastructure, then the application layer will depend on an interface in the infrastructure layer which feels weird.

If I declare the above interface in the application layer, then the `CommonDomainEventStore` will depend on domain interfaces and application layer interfaces.

If I declare this interface in the domain, it would feel weird since the `DomainEventStore` interface wouldn't depend on it, therefore there would be no guarantees that implementations would support metadata providers. I could add a method `setMetaDataProvider` on the `DomainEventStore` interface to force implementors to support a metadata provider, but now all implementations would have to become mutable.

I'm not so sure how I should define these dependencies? 

Colin Yates

unread,
Sep 22, 2016, 1:13:32 PM9/22/16
to ddd...@googlegroups.com
You might be overthinking this :-). What is the simplest thing that can possibly work?

--
  Colin Yates

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages