SOC против DRY в многоуровневой архитектуре

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

  • Должен ли я применять DRY и возвращать ответ от домена непосредственно клиенту. Но добавьте отдельный DTO для входящих запросов, которые обрабатываются интерфейсом, и сопоставьте его как модель предметной области.

  • Должен ли я применять SOC и отображать все объекты, входящие и исходящие из домена. Одна из моих основных проблем заключается в том, что добавление нового свойства потребует от меня обновления всех моих объектов как на веб-сайте, так и на домене.

Мне любопытно, что сообщество в настоящее время практикует с DTO в многоуровневой архитектуре, я искал как здесь, так и в репозиториях github, и большинство реализаций следуют первому (хотя это были только примеры проектов).

mediatr webapik

введите здесь описание изображения


.net c# webapi mediator
person dardardardar    schedule 04.10.2020    source источник
comment
Естественно испытывать отвращение к постоянному сопоставлению типов, особенно при отправке ответа, но такое дополнительное сопоставление изолирует ваш домен, позволяя безопасно проводить рефакторинг без нарушения работы клиентов. Если вы просто вернете свои модели домена напрямую, вы потеряете это. Помните, public != published. Вы должны думать об эволюционируемости вашей архитектуры таким образом, чтобы свести к минимуму поломку потребителей, и дополнительное сопоставление — это шаг, который поддерживает это.   -  person John H    schedule 04.10.2020
comment
Добавление вещей обычно не проблема; клиенты обычно не впадают в кризис, если вы отправляете им 10 свойств, когда они закодировали только 9. Наличие DTO не обязательно повторяется, даже если в некоторых случаях есть сопоставление 1: 1.   -  person Caius Jard    schedule 04.10.2020
comment
Спасибо, что подтвердили мне это. Я думаю, это хорошо, что существует automapper.   -  person dardardardar    schedule 04.10.2020
comment
@CaiusJard моя главная цель действительно состоит в том, чтобы сделать жизнь наших разработчиков немного проще за счет некоторой стандартизации. Я предполагаю, что в долгосрочной перспективе ремонтопригодность проекта всегда важнее всего остального.   -  person dardardardar    schedule 04.10.2020
comment
Я думаю, вы найдете это интересным: stackoverflow.com/questions/23648832/   -  person Stefan    schedule 04.10.2020
comment
Спасибо @Stefan, это что-то новое, я посмотрю на это. Ранее в этом году я обнаружил нечто подобное stackoverflow.com/questions/24588838/   -  person dardardardar    schedule 04.10.2020
comment
Сделать жизнь разработчика проще, убрав 10 секунд, которые им нужны, чтобы написать myDto.NewProperty = myDataEntity.SomePropertyIJustAdded, а затем щелкнуть лампочку и выбрать «Создать новое строковое свойство». и что вы будете делать с ним через x месяцев; добавьте свойства или дизайн таким образом, чтобы его можно было обновить без радикальных изменений формы в будущем, и это упрощает интеграцию для клиентов. Внутренне вы можете переписать все, если это необходимо   -  person Caius Jard    schedule 04.10.2020
comment
@CaiusJard да, наверное, я слишком много думал об этом.   -  person dardardardar    schedule 04.10.2020