Резюме

MVC — это шаблон проектирования программного обеспечения, который впервые был предложен Трюгве Реенскаугом в 1978 году. Он эффективно решил проблему, состоящую в том, что код уровня представления, уровня контроллера и уровня логики был перемешан вместе, и было хорошо достигнуто разделение обязанностей. Однако в реальном процессе кодирования вы обнаружите, что этот режим становится логически хаотичным с расширением бизнеса, и перекрытие кода очень велико. Здесь предлагается новая инженерная структура, основанная на концепции DDD.

проблема mvc

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

  1. 四层 controller/service/manager/mapper

  2. 不可以同级调用

  3. 上级可以知晓下级，下级不可知晓上级，也就是bean的转化放在上级

Это иерархическое разделение обязанностей разделено по вертикали.

  1. 资源服务层repository是面向DB编程

  2. service层是面向前端页面编程。

То есть для определенного дела он не абстрагировал логику воедино, а просто разделил запрос по вертикали. Горизонтального сегментирования бизнеса нет. Проблемы, которые это вызоветДецентрализованные обязанности и высокая логическая повторяемость

• Создание бинов слишком произвольное, в основном требование соответствует некоторым бинам dto, vo, query
• У разных разработчиков есть разные bean-компоненты для вещей в одной и той же области, и один и тот же разработчик определяет аналогичный bean-компонент для bean-компонентов с той же логикой через несколько месяцев.

нет границ

• Понятия контекста/границы вообще нет, например, магазин будет взаимодействовать с пользователем, а заказ будет взаимодействовать с пользователем, обычно в БД хранится только ассоциированный id, а потом уже соответствующее имя и прочее необходимо получить атрибутивную информацию. Для получения этой информации некоторые операции разрабатываются на уровне менеджера, а затем атрибуты определяются в связанной с магазином DTO, некоторые помещаются на уровень сервиса. Контроллер/сервис/менеджер можно вызывать на всех уровнях без каких-либо ограничений.

Эволюция MVC

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

Приведите несколько примеров из жизни

Примеры подбиблиотек и подтаблиц

Сущность A является базовой и важной сущностью в нашем бизнесе.Соответствующая таблица данных tableA, бизнес в начале очень прост, есть только одна служба, которая вызывается в этой службе. Позже бизнес расширился, и сервисов стало больше десятка, а потом еще больше десятка сервисов напрямую проверяли эту таблицу. tableA также расширяется до tableA, tableB, tableC. Некоторые люди считают, что повторение кода велико, поэтому слой картографа/менеджера разбивается на общие части и упаковывается в пакет jar, а затем jar вводится в каждый микросервис. Бизнес стал более сложным, сервис расширился до десятков, а данные таблицы А имеют десятки миллионов.В настоящее время необходимо создать подбазу данных и подтаблицу, как ее настроить.

В итоге потребовалось около года с участием более десятка команд, чтобы изменить вызов картографа/менеджера, а затем сделать подбазу данных и подтаблицу.

Кто-то может подумать, что достаточно избегать прямых звонков при разделении сервиса, и тогда привести другой пример.

Пример уровня пользователя

Уровень пользователя, уровень пользователя очень сложен, и разные этапы бизнеса имеют разные определения. Например, определите поле с именем Grade в начале для представления уровня пользователя. Затем каждое предприятие проверяет полевой класс этой таблицы, чтобы сделать выводы, а затем продукт необходимо изменить, и в то же время необходимо выполнить суждение, чтобы его назвали классом x. На этот раз вам предстоит снова изменить мир.

Инженерная архитектура DDD

Как использовать идею DDD для трансформации?Основная идея: инкапсулировать логику в домене, унифицировать открытый вход и предотвратить утечку бизнес-логики.

• На основе продольной сегментации mvc добавить слой горизонтальной сегментации поля
• В том же проекте вызовы между доменами могут выполняться только через domainService, который может скрыть то, как база данных в домене постоянна, как оценивается бизнес-логика и как реализуется алгоритм. можно вызывать непосредственно между службами.
• Поле по-прежнему разделено по вертикали, и установлена ​​многоуровневая структура mvc.

Вышеприведенное — это всего лишь набросок, наша реальная структурная схема немного сложнее. Домен будет различать объекты домена, службы домена и уровни инфраструктуры. Таким образом, вина отделяется в поле.Однако из деталей сравнения в поле в фактическом процессе реализации рентабельность инвестиций относительно низкая.Рекомендуется сначала следовать этому набору реализации.

Голос за кадром: Подсчитано, что некоторые программисты рассмеялись, увидев это изменение в структуре проекта, и посчитали, что оно не имеет большого значения и что нет необходимости его менять.

Структурное подразделение этого проекта составляет около 8 месяцев с момента его предложения до фактического принятия членами нашей команды. Причины, вероятно,

1. Внедрение новых слоев, слишком сложных, усложняющих код
2. Мой бизнес очень простой, CRUD достаточно, а взаимодействия между сервисами нет. Вы можете перейти прямо к черному по mvc.

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

Эволюция разработки DDD

Эволюция проекта DDD заключается в разделении сервисов, о чем пойдет речь в следующем выпуске.

Суммировать

Во многих статьях DDD говорится, что традиционный метод программирования заключается в опросе программирования базы данных, в результате чего в объекте используются только геттеры и сеттеры, то есть модель анемии.Модель анемии не имеет бизнес-логики, процессно-ориентированного дизайна и не соответствует принципу объектно-ориентированного проектирования.

Я согласен с этим выводом, но не согласен с причинами. Лично я думаю, что главная причина этого в том, что долгосрочная модель MVC вызвана только вертикальной сегментацией. Если комбинировать горизонтальную сегментацию, то неважно, есть DDD или нет. Цитата еще раз здесьМетод привода ничего не меняетВ этом пункте, если вы можете глубоко понять ответственность и инкапсуляцию. А с итерацией бизнеса, постоянным рефакторингом вашего кода, вам не нужны ни DDD, ни другие методологии.

ответственность использования, инкапсуляция и композиция; Думайте с точки зрения интерфейсов, то есть «Как люди используют мои компоненты?»; Пишите хороший код, используя соответствующие технологии, в том числе удобочитаемость, информативность, лаконичность, самоописание и старайтесь избегать явного использования шаблонов; Умение ответить на «суть» того или иного дела; «суть» — это модель, а не классы и методы, это означает ответ на вопрос «Как на самом деле работает этот бизнес?»

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

Следующая статья — разделение полей и микросервисов, если хотите узнать, что будет дальше, слушайте следующую декомпозицию.

Связанное Чтение

Landable DDD(1) - Обсуждение цели

Обратите внимание на [Храм аббата], как можно скорее получите обновление статьи и начните путь технической практики вместе с аббатом.