1

Solution insight and problem.

There are multiple BC in my solution, which at some point will be translated as microservices. At this point everything will run under the same process thus an unknowingly someone could just add references wherever he/she would like, which of course is not desirable if we are to keep the structure.

So what I'm asking is how do you enforce a rule that there will be no dependencies between BC, and I'm not talking about pull-request, the problem should be immediately evident for anyone who is trying to use something from another BC aside from the one he/she is working one at that point.

I want to enforce a rule of dependency blocking in my solution, from one project to another (BC-to-BC).

The check upon the broken dependencies should be made at build and result in a compile time error.

Is there any way this can be done ? How ?

2 Answers2

2

Yes it is definitely possible using .Net Architecture diagrams. For instance take a look at dependency diagrams. Once you have modeled the desired architecture you can add the Microsoft.DependencyValidation.Analyzer package to your project which enables live validation of architecture dependencies and gives compile time errors if these dependencies are broken. The package is available as a NuGet package and works for .NET projects in VS2017.

i regular
  • 584
  • 6
  • 16
0

You could take a look at using the "Internal" keyword which you could use to protect your assembly classes from being accessed. There's a more comprehensive answer here: Practical uses for the "internal" keyword in C#

Kamil Kuryś
  • 62
  • 6
  • Doesn't help I don't want to do that. How would i access them from projects that are allowed to do that ? –  Jan 13 '19 at 10:30
  • You could grant access to specific assemblies with the [InternalsVisibleTo](https://learn.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.internalsvisibletoattribute?view=netframework-4.7.2) attribute (not that that is a great idea for this purpose). – John Wu Jan 13 '19 at 11:10
  • Why is it not a good idea for this purpose? It requries some additional work, but this is exactly the thing for this kind of a requirement. – Kamil Kuryś Jan 13 '19 at 11:55
  • You can make the classes internal and expose the behaviour with interfaces and dependency injection by for instance using Castle Windsor. To do this you will have to define methods that allows to register the classes of the loaded assemblies in the Winsor container, but it is definitely possible - we do it a lot. However, this will of course not give you any compile-time errors – i regular Jan 13 '19 at 12:11