I am new at DDD and I came up with a question about a implementation that I recently made. The User layer of my DDD project asks the application Layer for a IModel type object for connecting to a RabbitMq Brooker. Then the application layer asks a domain layer service for a IModel, that finally delegates to the Infra Layer that task (through Interface implementation). It works fine, but the question is: is it against the DDD principle the Domain layer have knowledge of another project? Even though it is a Nuget package project.
2 Answers
Yes. Domain layer should be the very center of your architecture and it cares just about domain rules and invariants. All the coordination and plumbing should go into Application layer.
A good start is Onion Architecture or Hexagonal Architecture
Also check this DDD Decoded post (it worth taking a look at the complete DDD Decodes serie) to see a implementation about how use the application layer to coordinate the business with all other things.
Note you are asking two different questions.
Domain Driven Design (DDD), can my domain have a reference to a RabbitMQ or to any other nuget package?
NO
is it against the DDD principle the Domain layer have knowledge of another project?
YES
The domain should have the fewest dependencies possible. So your domain layer should not have NuGet packages in it (in General).
now your domain layer can have an interface that you know will most likely be filled in the application layer by a provider. but this interface should be your interface, not an interface provided via a third party.
If you know you are to use a third party object later in the application. I think pure DDD would have you write your own interface then use the adaptor pattern to convert third party implementation to work with your interface.
So, in this case, your Domain level does not have any outside dependencies or knowledge of what is in the application layer.
Related