The Sin.Net Project
The binaries are developed with
.NET Standardso that every kind of .NET related project can use them. You can integrate the assemblies as
NuGetpackages, for more information please take a look into the NuGet Gallery. If you want to look into the
source codeitself, you can find the project on GitHub - Sin.Net.
The implementation of clean architecture follows mostly the ideals of Jason Taylor - so thank you Mr.!
To give you a brief overview how it works, please look at the flow chart below.
layer represents one or more assemblies in your app. To be clear each box carries the word layer.
Now I will state out some principles for each layer. Please note that this list has not the intention to be complete. So you might consider to check further literature or contact me in case of emergency.
domain layerholds interfaces, abstractions and implementations that are intended to be used across different applications. These should belong to the same application field (domain). In other words: If you or your company has a bunch of software that maybe interact with each other, it is a good idea to place shared definitions (and in some circumstances the implementations) in this layer.
All definitions and implementations, that are specific for your one and only application, reside in the
application layer. This layer has only one dependeny: the domain layer (like shown in the graph). That means that your domain layer should have no dependencies, except the Sin.Net.Domain.dll.
The persistence layer and the infrastructure layer are more or less one outer layer that takes care of two similar tasks.
Like the names are revealing, the
persistence layercovers all implementations to access your local system like files or databases. The interfaces that are in use here, should come from the domain or application layer.
infrastructure layerimplements functionality to access remote services like other web services, Email or whatsoever. It is recommended to split this outer layer into these two named assemblies, to ensure a high independency when developing or updating these libraries. And working in a team becomes also more clear.
In the Sin.Net project this layer also has a separate logging assembly that could be seen as a part of the persistence layer. This DLL demonstrates how to implement your own logging mechanism, or for the lazy ones, just integrate it.
Last but not least the
presentation layerdepends on all layers below. This highest layer only plugs things together and ships your UI, so the user can interact with your system. This layer should be the most lightweight one, which is a good idea in the fast moving world of user interfaces.
As you might see, the Sin.Net assemblies are bypassing the application layer. That is - of course - because I can’t provide this layer to you. Maybe if you pay me. But if you decide to use the Sin.Net.Domain.dll it makes sense to build your upper layer’s based on its interfaces and abstractions. In the best case you just use the other assemblies too and maybe extend them within your own layers.
This could be a potentional (and most comprehensive) implementation of the Sin.Net Project. What’s also not illustrated here, is a project for unit testing your app, but you should definitely have one.
Now, if you like this way of organizing your software architecture, please take a deeper look into the videos or blog posts of Jason Taylor, because he explains that stuff with lots more details. And if you like to test some ready-to-go assemblies that follow these principles, please download the Sin.Net assemblies and use them according to your requirements.
Have a nice day!