How to ensure the integrity of project references when the namespace between layers is the same?

[HHobeck]

Hi there.

In my projects I'm following the domain driven design paradigma and name the system namespaces without including any technical aspects like Service, BusinessLogic and Repository (a classic 3-layer architecture). Of course the technical implementations (layers) of the domain models are isolated via different assemblies but living within the same namespace.

For example:

• MyCompany.Service.dll references MyCompany.ServiceContract.dll and MyCompanyRepositoryContract.dll
• MyCompany.Repository.dll references MyCompanyRepositoryContract.dll

To my question: How would you ensure the integrity of the layers if you want prohibit a reference from, for example, the layer MyCompany.Repository.dll to MyCompany.ServiceContract.dll?

[realvizu]

Let me rephrase your question to see if I got it. So you use namespaces and assemblies as two orthogonal dimensions to divide up your application: you use namespaces for the business areas and assemblies for the technical layers, right?

Unfortunately this structure doesn't make it possible to use NsDepCop for controlling dependencies between technical layers, because those are not identified by namespaces, but by assemblies. And NsDepCop checks dependencies only between namespaces.

I see a couple of options though.

(1) Use some other tool for controlling dependencies between assemblies.
E.g. https://github.com/TNG/ArchUnitNET lets you write tests that check architectural rules. So you could use it to test that there are no prohibited assembly references.
This seems like the simplest solution.

(2) Reorganize namespaces so you can use them to represents both domain (business area) and technical (layer) aspects.
E.g. you could have namespaces like:

• MyApp.ProductCatalog.ServiceContract, MyApp.ProductCatalog.Service, MyApp.ProductCatalog.RepositoryContract, etc.
• MyApp.OrderProcessing.ServiceContract, MyApp.OrderProcessing.Service, MyApp.OrderProcessing.RepositoryContract, etc.
• etc.

This approach has the benefit that you can define much more fine grained dependency rules between namespaces than it would be possible with just assemblies.
E.g.

• MyApp.OrderProcessing.Service can depend on MyApp.OrderProcessing.ServiceContract, because it implements it.
• MyApp.OrderProcessing.Service can depend on MyApp.ProductCatalog.ServiceContract, because it can use it.
• But you don't want to allow all things in the Service layer to use all things in the ServiceContract layer.

I've got a blog post that further elaborates on this topic: https://realvizu.com/2018/02/03/implementing-ddd-bounded-contexts-with-csharp-namespaces-and-dependency-rules/

As a side note: you could have many sub-namespaces under each layer-identifying namespace.
E.g.

• MyApp.ProductCatalog.Service.Search
• MyApp.ProductCatalog.Service.Pricing
• etc.

[HHobeck]

I have created a pull-request. Please take a look: #81

Following points are open:

• renaming from AllowedAssemblyDependency to AllowedAssembly
• renaming from DisallowedAssemblyDependency to DisallowedAssembly
• creating CheckAssemblyDependencies attribute in NsDepCopConfig
• addding the new diagnostic to the doc/Diagnostics.md file
• writing unit tests

[HHobeck]

Done. Wish you a happy new year! ;)

[realvizu]

Thanks a lot for your work, I'll review it soon.
Happy new year to you too!

[realvizu]

PR merged, I will release the new nuget version soon.
Thanks again!

[HHobeck]

@realvizu: Please see the discussion dotnet/roslyn#50574 (comment)

[realvizu]

Nuget released: https://www.nuget.org/packages/NsDepCop/2.5.0