Недавно было обнаружено, что статьи всегда были украдены, а некоторые платформы сообщали о них и не использовали их. пожалуйста, идентифицируйте мой идентификатор方丈的寺院.

Резюме

Дизайн, ориентированный на предметную область, DDD возник из его самой влиятельной и известной книги, опубликованной известным экспертом по моделированию Эриком Эвансом в 2004 году: Проектирование, ориентированное на предметную область — решение проблем в основе программного обеспечения (китайский перевод: Проектирование, управляемое предметной областью, после многих итераций). и эволюции, но большинство из них не выходит за рамки этой книги. Потому что Эрик Эванс предоставляет в этой книге только набор оригинальных теорий, а не набор методологий, не говоря уже о посадке. Таким образом, для более чем десяти лет, для DDD Противоречие, неоднозначная репутация, люди, которым это нравится, думают, что он решает сложность проектирования программного обеспечения, люди, которые не думают, что он усложняет дизайн кода.

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

Почему DDD так сложно внедрить?

Гибкая итерация, отказ от моделирования

В состав современной группы по производству и исследованию Интернета обычно входят рынок/эксплуатация, продукт, взаимодействие с пользовательским интерфейсом, интерфейсная часть, внутренняя часть и тестирование. Разделение труда этих ролей состоит в том, чтобы разделить различные процессы разработки и запуска продукта, а затем каждый процесс несет ответственность, что может эффективно повысить эффективность производства.Этот набор процессов является стандартным.сборочная линия. Плюсы в этом неоспоримы, минусы тоже очевидны: каждый сосредотачивается только на своемигнорировать все.

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

• Унифицированный язык (все разработчики/пользователи программного обеспечения используют один и тот же язык, то есть познание понятия и существительного унифицировано)
• Предметно-ориентированный (мышление в терминах доменов, а не модулей)

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

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

Давайте сначала посмотрим на преимущества единого языка и доменной ориентации.

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

На первый взгляд, эти преимущества на самом деле значимы для всех ролей в разработке продукта. Но присмотритесь, стоимость связи значительно снижается, и нет проблем с работой, продуктом и взаимодействием с пользовательским интерфейсом. Если понимание проблемы противоречиво, достаточно организовать встречу и хорошенько поболтать. Какая польза от последовательного пользовательского опыта для производственной и исследовательской группы?В любом случае, пользователь ругает не меня, а заказчика и операцию. Какая польза от глубокого анализа внутренней логики продукта? Есть много факторов успеха продукта, в основном полагающихся на вышеперечисленное, я просто солдат, я не могу так много контролировать. Когда у меня будет время, я проведу больше исследований в своей области знаний и прочитаю больше статей с интервью. Продукт желтый, и я хочу прыгнуть с корабля.

Поскольку я занимаюсь внутренними исследованиями и разработками, я не буду слишком подробно рассказывать о других ролях. Я просто хочу сказать R&D, не могли бы вы сменить работу и компанию? Грязный еще мальчик. По-прежнему повторяется множество избыточных функций и избыточного кода. Вы можете написать все, что попросит вас написать заказчик, и в конце концов вы потеряете интерес к коду и свои мечты во время сверхурочной работы изо дня в день. Мы все знаем, что трудно изменить других, поэтому мы должны начать с изменения самих себя и сделать себя лучше, прежде чем мы сможем влиять на других.

Фреймворки легко изучить, идеи трудно изучить

Если отбросить другие роли, рассматривайте DDD только с точки зрения исследований и разработок. Разработайте моделирование предметной области, а затем следуйте закону Конвея, чтобы сопоставить проект архитектуры программного обеспечения с бизнес-моделью. (Хотя в этой области разработка может быть неправильной, пока игнорируйте эту проблему)

Закон Конвея (Мэл Конвей) Когда какая-либо организация проектирует систему (систему в самом широком смысле), поставляемый проект структурно соответствует коммуникационной структуре организации.

Почему так сложно внедрить DDD в чисто R&D?

нет стандарта

DDD — это набор идей, набор схем моделирования предметной области и набор, используемый в конкретном контексте. Таким образом, с 1000 команд, выполняющих DDD, может быть 1000 различных сценариев. Человек, который много лет практиковал DDD, сменил компанию, сменил команду, привёз свой первоначальный набор и продолжил его, это вообще неприменимо.

Таким образом, изучение и практика DDD — это не изучение функции, API или фреймворка, которые имеют прямой эффект обратной связи, а должны быть реализованы в сочетании с реальной ситуацией в команде для достижения эффекта.

С нетерпением жду, когда DDD решит все проблемы

Программисты очень практичны, и они не будут делать то, что не приносит пользы. Вы должны быть в состоянии эффективно помочь ему стать лучше, прежде чем он примет это. Например, когда член команды предложил,

После того, как мы внедрим этот набор, не нужно ли будет работать сверхурочно, или сверхурочные часы можно сократить?

Предлагаются тесты

После реализации этого набора, насколько можно снизить процент багов.

НИОКР нужен количественный эффект, извините, DDD не может этого сделать. Ни одна команда не реализует DDD и не решает все проблемы в разработке программного обеспечения. Об этом вы можете прочитатьМетод привода ничего не меняет

Цель посадки DDD

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

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

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

дальнейшее чтение

Landable DDD (2) — почему инженерная архитектура MVC устарела

Landable DDD (3) — Как использовать DDD для разделения микросервисов

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