Первая пуля «Обычного ДДД»: восемнадцатилетний ДДД

DDD, знакомое имя, которое кажется неизвестным. В этом году ему исполняется 18 лет.

В конце 2017 года я принял участие в первом «Китайском саммите по проектированию доменных имен», организованном моим старым клубом в качестве волонтера в Пекине. Многие известные отечественные люди собрались, чтобы обменяться опытом и идеями о DDD, а также некоторые иностранные гости. Более месяца назад «Саммит-2020» также прошел в онлайн-режиме, как и было запланировано. Видите ли, прошло несколько лет, а DDD все еще интересует всех, да и статус DDD в текущей архитектуре ПО тоже налицо.

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

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

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

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

Неразрывная связь между DDD и микросервисами

Еще в 2003 году Эрик опубликовал знаменитый «Domain-driven Design», на который у него ушло 4 года. Иными словами, Эрик начал задумывать и писать DDD в 1999 году, почти двадцать два года назад. В течение более чем 20 лет он может быть незначительным в других областях, но его хватило, чтобы снова и снова совершать технологические скачки в области программного обеспечения и Интернета. Трудно представить, что по прошествии более 20 лет идея программной архитектуры не только не исчезла, но и снова омолодилась!

Говоря об этом, DDD должен поблагодарить появление микросервисов. В последние годы в связи с бурным развитием интернет-индустрии система приложений становилась все более сложной, что породило идею микросервисов. Микросервисы выступают за разделение и завоевание бизнес-единиц, а каждый модуль автономен, что снижает сложность системы. По совпадению, это то же самое, что и идея, ограниченная контекстом, предложенная DDD в разделе стратегического проектирования. Если вы читали оригинальную книгу Эрика, у вас может даже возникнуть иллюзия, что микросервисы кажутся производными от DDD. И с помощью DDD для управления дизайном микросервисов вы также обнаружите, что почти нет очевидного чувства несоответствия. Из-за этого DDD можно омолодить за счет популярности микросервисов, которые также являются ценным воплощением «стратегического дизайна» DDD и наиболее важным воплощением ценности DDD в текущей среде.

Что такое ядро DDD?

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

Чтобы понять суть DDD, мы должны понять его позиционирование и значение. Когда Эрик написал книгу DDD, он дал ей подзаголовок:

«Преодоление сложности в основе программного обеспечения».

Это предложение для DDDпозиция, тоже авторская идея. Суть понимания этой фразы в том, что "основной"а также"сложный«Два слова, понимание конструкторских идей DDD и практика посадки, должны быть приняты во внимание.основной комплекс. другими словами,DDD не панацея от всех проблем, у него есть четкие сценарии применения. Поняв это, вы также должны понять, что DDD — это просто молоток в наборе инструментов для архитектуры, и когда использовать этот молоток, зависит от ситуации. Если ваша проблема достаточно сложна, DDD может быть вашим первым выбором.В противном случае могут быть лучшие альтернативы, если вы выйдете и повернете направо.

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

путем моделированияСосредоточьтесь на сферах бизнеса, решать сложные задачи в полевых условиях;
пройти черезобщий языкустранить коммуникативные барьеры;
Отражение модели предметной области и логики предметной области через код;
Улучшайте модель путем непрерывной эволюции;
Разделите поддомены по контексту;

В переводе на местный язык это выглядит следующим образом:

В отношении сложности программного обеспечения не стоит обращать внимание только на техническую сложность, сложность, вызванная логикой предметной области, более важна и долговечна;
Будь то разработка, продукт или эксплуатация, пожалуйста, объедините свой уровень и риторику;
Этот универсальный язык предназначен не только для разговоров, вы должны использовать модель для отражения предметной области в коде;
Необходимо оставаться рядом с бизнесом, принимать изменения и постоянно корректировать и оптимизировать модель предметной области;
Большой ком грязи — это плохо, поэтому нам нужно разумно разделять подобласти и границы, а также разделять и властвовать.

Понимаешь, суть DDD не что иное, как понять сложно?Это не имеет ничего общего с технической практикой или выбором языка., даже вам может казаться, что вы освоили DDD, это немного транс? Правда в том, что Эрик придумал не столько DDD, сколько хорошее имя. Вы знаете, обсуждение моделирования и объектной ориентации в основе DDD было очень популярно в ту эпоху, и различные методы процветали. Моделирование на основе предметной области — не первое творение Эрика.Рисунки по сравнению шаблонов проектирования, ориентированных на данные, и шаблонов проектирования, управляемых предметной областью, приведенные в нижней части этой статьи, взяты из книги Лао Ма, опубликованной в 2002 г. продвинутый чем ДДД.Годом раньше, до сих пор не устарел. Но я должен сказать, что имя Эрика очень хорошее, и некоторые концепции лучше отработаны. Это похоже на Agile Manifesto, появившийся в то же время.В 1990-х годах преобладали различные программные методы, такие как Extreme Programming, Crystal Method, DSDM и т. д. Эти программные методы тоже кажутся расцветающими, но на самом деле все они имеют одинаковую коннотацию. В результате некоторые старые эксперты выдвинули «Аджайл-манифест» в сочетании с теориями сотен школ мысли во время катания на лыжах.

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

На практике многие люди также могут подумать, что agile — это новая волна мышления, и они мало что о ней знают. Как всем известно, после двух десятилетий разработки agile-практики уже расцвели повсюду и незаметно стали частью текущего процесса разработки программного обеспечения, но вы можете этого не осознавать. Например, отдел эффективности Alibaba собрал много agile-экспертов в отрасли и хорошо разбирается в методах agile.Они встроили agile в процесс разработки.Вы можете не знать об этом, но вы на самом деле в нем участвуете. То же самое относится и к DDD: за последние 20 лет разработки многие элементы DDD также оказались бессознательными, например, ограниченный контекст микросервисов.В какой-то степени можно сказать, что они исходят не от DDD, а от среды и трендов.

Каковы преимущества практики DDD?

Говоря о преимуществах DDD, большинство людей могут использовать следующую картинку (из книги Лао Ма «Шаблоны архитектуры корпоративных приложений», опубликованной в 2002 году):

Что означает эта картинка,По сравнению с шаблоном проектирования, ориентированным на данные, шаблон проектирования, ориентированный на предметную область, может лучше выдержать испытание временем.Сложность будет увеличиваться линейно с увеличением времени.Линейность означает порядок и не выйдет из-под контроля.. Так как же она увеличивается линейно? В основном двумя способами:

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

Контроль сложности, достигаемый этими двумя способами, делает систему следующих преимуществ:

Оптимизация структуры кода: многоуровневая структура кода более понятна, ее легко расширять и поддерживать;
Логическая связность домена: логика домена находится в одном месте, а поведение домена можно многократно использовать;
также,Хорошо организованный код также более удобочитаем и тестируем..

Каковы недостатки и стоимость использования DDD?

Бесплатных обедов не бывает, то же самое и с DDD. Чтобы насладиться ценностью DDD, нам также нужно заплатить высокую цену. Например, нам нужно заплатить за следующие затраты:

кривая обучения:
- Новые дизайнерские идеи и принципы;
- новый режим;
- новый процесс разработки;
время и усилия:
- При моделировании необходимо общаться и обсуждать с экспертами предметной области;
- Выделить логику предметной области из сложной информации и модулей;
Только в сложных задачах можно отразить значение DDD:
- Для проблем, которые можно решить с помощью CRUD, не используйте DDD, но это усложнит проблему;
- Чисто технические приложения, не используйте DDD;
продвижение и распространение:
- Один поток не может сформировать поток, а одно дерево не может сформировать лес. Если вы хотите получить широкое признание самостоятельно, вам может быть более подходящим для вас склонить голову перед контрактом на развитие спроса;
- Вам нужно продолжать проповедовать и проповедовать, продолжать получать поддержку от организации, продолжать достигать консенсуса с партнерами, продолжать охранять структуру и продолжать учиться.

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

Почему DDD так сложно понять?

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

Например, что вы собираетесь делать, практикуя общий язык в команде? Если вы не знаете, кто-нибудь скажет вам, что вы можете использовать гибкую разработку программного обеспечения, SCRUM, пользовательские истории, карты пользовательских историй, Inception и многое другое. Вы растеряны? В расширенном виде можно было бы написать книгу на тему того, как практиковать «пользовательские истории». А по линии «пользовательских историй» вы также можете задействовать кучу инженерных методов, о которых вы, возможно, не слышали.

Другой пример: как универсальный язык вписывается в код? Если вы не знаете, кто-нибудь скажет вам, что вы разрабатываете модели предметной области, доменные службы и используете CQRS, поиск событий, штурм событий, модульное тестирование и многое другое. С таким количеством необъяснимых понятий вы снова запутались? Например, часто упоминается CQRS, неужели он такой ароматный? Помните здравый смысл, любая технология имеет свои применимые сценарии и свои ограничения. А когда дело доходит до модульного тестирования, эта куча фреймворков снова может выпить два горшка.

Бесконечное расхождение и интерпретация DDD является важной причиной, из-за которой кажется, что его трудно понять, а также искусственной причиной.. DDD никогда не имел фиксированной структуры и не ограничивался JAVA или конкретным языком. Если есть, то, наверное, потому, что кто-то хочет получить результат, кто-то хочет прославиться, а кто-то хочет получить прибыль, и это искусственно усложняется. Я не хочу никого здесь принижать.Я работал в консалтинговой компании, и я часто общаюсь в некоторых кругах программных методов.Я относительно знаком с некоторыми процедурами.Стекирование концепций и расходящихся тем является обычной практикой некоторых бронзовых консультантов. Например, «сложный» вроде бы состоит всего из двух слов, но можно рассказать о сути сложности, откуда берется сложность ПО и т. д., а также можно расширить фреймворк Cynefin.Все, что непонятно, в двух предложениях Можно вытащить и сделать так, чтобы это звучало, но это не очень полезно, в основном используется для блефа, и я сам так делал.

Итак, чтобы понять DDD, вы должны найти его истинные цвета в оригинальной работе, а не слушать навороты. Эти маленькие мысли в этой статье не стоят вашего пребывания..

Вернуться к реальности, делать или не делать?

На этот вопрос нет фиксированного ответа.

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

DDD не сложен, его ядро незамысловато, и вы, возможно, уже тренируетесь;
DDD не панацея.В большинстве простых бизнес-сценариев не нужно рассматривать использование DDD.Для сложных бизнес-задач приоритет отдается DDD;
Не существует идеальной практики DDD и абсолютно правильного метода DDD;
Обратите внимание на модель предметной области, обратите внимание на общий язык, обратите внимание на объектно-ориентированный подход, забудьте об одержимости DDD, забудьте об ограничениях фреймворка;
DDD никогда не был камнем преткновения для обновления архитектуры и расширения бизнеса, и никогда не беспокоил нас DDD.Что нужно сделать, это гораздо больше, чем DDD;
В 2009 году на конференции QCON в Лондоне, через шесть лет после публикации DDD, Эрик полагал, что фокус DDD сместился с организационной бизнес-логики наОткройте для себя доменную архитектуру. В то же время Эрик также считает, что модель предметной области по-прежнему является хорошей моделью для организации бизнес-логики, но объектно-ориентированное, функциональное программирование, CQRS и трехуровневая архитектура также являются хорошими моделями. Подумайте о последних десяти годах, фокус DDD все еще меняется. Нет возможности попробовать его тщательно, это будет безумие, если вы его попробуете.

Конечно, сейчас многие люди ищут какую-то фиксированную структуру в процессе практики DDD.Это правда, что применение фреймворка — это наименее ошеломляющая вещь, и оно также может эффективно снизить практический порог DDD на тактическом уровне, но должно быть ясно, что это не весь DDD и не ядро DDD. .. В противном случае никакая рамка не помешает вам насыпать в него тарелку спагетти.

На самом деле, большинству разработчиков не нужно зацикливаться на DDD, а практичнее просмотреть базовые книги, такие как «Рефакторинг», «Гибкая разработка программного обеспечения» и «Чистая архитектура программного обеспечения»..

Дальнейшее чтение и ссылки

Старые эксперты говорят о DDD:Martin Fowler.com/B оставить/купить…
То, что вы ищете, может быть здесь:GitHub.com/привет, Ник С/Арвин…
InfoQ woohoo.info Q.com/domain-Dr IV…
www.domainlanguage.com
www.dddcommunity.org
2020 "Китайский саммит по доменному дизайну"

Обратите внимание на общедоступную учетную запись [MetaThoughts] и своевременно получайте уведомление об обновлении статей колонки.