c# – Application Architecture Review


There is a solution divided into the following layers : DAO , DAL , Services Gui where,

  • DAO – classes that describe domain models are stored here;
  • DAL – Generic Repository and its implementation;
  • Services – here I have methods of the following type: IEnumerable<Entity> GetEntities() ;
  • Gui – client side

I foresee immediately the question of how Services differs from Repository, in the repository I have basic CRUD methods:

void Create(Entity entity);
void Update(Entity entity);
void Delete(Entity entity);
IQueryable<Entity> Table {get;}

in Services , I build more complex queries: connections, grouping for example:

var _orders = получаем данные;
var _histories = получаем данные;
var orders = _orders.Join(_histories, o=>o.Id, h=>h.OrderId,(o,h)=>new OrderView
                        //Формируем необходимое представление

well, etc.

the dependencies between projects are as follows:

  • DAO connected as a reference in DAL, Services, Gui
  • DAL connected as reference in Services, Gui
  • Services included as a reference in the Gui

I want to make the project so that further support would cause as few problems as possible.

Did I do the right thing by dividing the project into smaller parts, or did I do it in vain and it is necessary to merge everything into one project and do the division at the directory level inside the solution and the namespace .

I would be very grateful for the links to the literature that is worth reading to clarify for myself how to properly build an application framework


There are many different ways to design an application. As I can see you are trying to use DDD . This pattern is quite universal, but it is not a silver bullet, and it also has a lot of implementation variations, for example, CQRS + ES or DDD + Onion, which have their own purposes, and with it their pros and cons.

Besides DDD and its variations, there are such architectural patterns as EDA , SOA , NLayer and others.

So that support does not cause big problems, you must first choose the right architecture, and this is not only a matter of choosing the right pattern, but of the language, technology stack, and much more. The choice itself depends on the problem being solved and various conditions.

Scroll to Top