Ревью Архитектуры приложения

#c_sharp #архитектура #шаблоны_проектирования #инспекция_кода

Есть решение разбитое на следующие слои: DAO, DAL, Services Gui где,


DAO - здесь хранятся классы описывающие доменнные модели;
DAL - Generic Repository и его реализация; 
Services - здесь у меня методы по типу следующего: IEnumerable GetEntities();
Gui - клиентская часть


предвижу сразу вопрос чем Services отличается от Repository, в репозитории у меня
базовые методы CRUD:

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


в Services же у меня строются более сложные запросы: соединения, группировка например:

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


ну и т.п.

зависимости между проектами следующие:


DAO подключен в качестве reference в DAL, Services, Gui
DAL подключен в качестве reference в Services, Gui
Services подключен в качестве reference в Gui


Хочу проект сделать так что бы дальнейшая поддержка причиняла как можно меньше проблем.

Правильно ли я поступил разбив проект на более мелкие части, или я сделал так зря
и необходимо слить все в один проект а разделение сделать на уровне директорий внутри
решения и namespace.

Буду премного благодарен за ссылки на литературу которую стоит почитать что бы прояснить
для себя как правильно строить каркас приложения
    

Ответы

Ответ 1

Есть самые разные способы проектирования приложения. Как я вижу вы пытаетесь использовать
DDD. Этот паттрен достаточно универсален, но не является сильвербуллетом, а так же
имеет очень много вариаций реализации, например CQRS+ES или DDD+Onion которые имеют
свои назначения, а вместе с ним свои плюсы и минусы.

По мимо DDD и его вариаций, существуют такие архитектурные паттерны как EDA, SOA,
NLayer и другие.

Что бы поддержка не причиняла больших проблем, нужно сначала выбрать правильную архитектуру,
а это вопрос не только правильного выбора паттерна, но языка, стека технологий и многого
другого. Сам же выбор зависит от решаемой задачи и различных условий.


Ответ 2

Был у меня опыт разработки именно при такой архитектуре, только за место Entity Framework
использовался NHibernate. Ну и был еще один дополнительный слой абстракции для веб
сервисов. То бишь было параллельно несколько веб сервисов, которые пользовались фунциями
из слоя Services. 

В целом код получался весьма читабельным и понятным. Но вместе с этим при реализации
функции в GUI приходилось протягивать эту функцию через все слои это со временем начинало
бесить. Получалось как-то слишком много лишнего кода который приходилось писать лишь
из-за всех этих слоёв. Дебаг так же происходил чуть медленнее. Были некоторые трудности
с определением того куда стоит засунуть функцию, в DAL или Services. В целом считаю
данную архитектуру весьма адекватной для решения многих задач. Она предлагает высокую
степень гибкости и читабельности, но может стать очень громоздкой. Что бы избавиться
от громоздкозти этого монолита мне кажется, можно было бы начать отщипывать от монолита
микросервисы.