The usual way (that I’m familiar with) to divide the server side is the n-layer architecture :
- DAL – data access layer, usually has the Entities and the context (and maybe include also a repository)
- BLL – business logic layer
- Contract – Interfaces
- Services – classes which implement the interfaces ( could be a Web API for E.G )
Of course there is also the n-tier Architecture which i don’t want to discuss .
lately I’ve seen more and more a “Modules” architecture and i was wondering about it ( I’m not familiar with the professional term of this architecture )
Where each module is not a table in the database but a group of tables that have a shared concept .
something that looks like that :
Is there any known good architecture that separate the layers by modules on the server side? if so, what is the professional term for this kind of architecture and what are the advantages / disadvantages of each of this architectures ?
2
Is there any known good architecture that separate the layers by modules on the server
side?
Modules and layers are two different concepts. Layers are typically used to describe the way code is deployed in a environment. However, Modules is about organizing code according to the functionality. There are other perspectives to modules where it could be based on project need, release order etc. The bottom line is module is a code organization mechanism in a solution layout.
What is the professional term for this kind of architecture and what are the advantages / disadvantages of each of this architectures
I am not aware of a professional term for the code organization shown in the image. However, let me convey what I think on the image. It is a mere code organization technique in a solution. It has very little to do with the architecture. Agreed, code organization is part of architecture. But, not sure if there is nomenclature for that. My opinion on such an code organization would be
-
The project focuses more on functional organization of code indicating a rich domain. People in team understand domain much better. Thus the team might have found this organization as more natural.
-
Disadvantage for this type of code organization is many C# projects. Instead of having a project for all contracts and sub folders based on modules, you are having projects for each functionality which are later stiched together.
-
Another disadvantage I could see is lot of assemblies involved might drag your performance down.
Hope this helps.