1

The usual way (that I'm familiar with) to divide the server side is the n-layer architecture :

  1. DAL - data access layer, usually has the Entities and the context (and maybe include also a repository)
  2. BLL - business logic layer
  3. Contract - Interfaces
  4. 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 :

Modules and DAL architecture

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 ?

closed as too broad by gnat, Bart van Ingen Schenau, World Engineer Apr 15 '14 at 14:15

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

1

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.