Ну, во-первых, я не думаю, что статья в Википедии, на которую вы ссылаетесь, очень хороша, в основном потому, что она ссылается на кучу вещей, которые являются вспомогательными только для Domain Driven Design, и мало что делает для ознакомления кого-либо с практикой.
Но, как человек, который воспринял доменно-управляемый дизайн близко к сердцу (что обычно стоит в DDD, а не в 3D, для чего это стоит), я всегда чувствовал, что основы DDD очевидны, если вы читаете так много, как первая глава Эрика Книга Эванса. Но это набор шаблонов и практик, поэтому не так просто дать краткое изложение из трех предложений о том, что это такое и каковы преимущества, не вдаваясь в некоторые подробности. Какие детали резонируют с каким-то одним человеком, тоже может сильно отличаться; вполне вероятно, что 10 лет назад я бы вообще не увидел в этом смысла.
DDD это не серебряная пуля. Когда все сделано разумно, речь идет о мастерском подходе к созданию программного обеспечения и признании необходимости уменьшить когнитивные трения между командами разработчиков и предприятиями, для которых они создают программное обеспечение. Одним из наиболее важных методов является создание слоя, в котором словарь домена, используемый командой разработчиков программного обеспечения и бизнес-группой, максимально соответствует друг другу. Вы строите этот слой итеративно, когда понимаете бизнес-проблему, которую пытаетесь решить. Когда бизнес-логика разумно закодирована на этом уровне, изолирована от всех запутанных зависимостей, которые обычно имеют корпоративные приложения, путем разделения взаимодействий с этими системами на интерфейсы, язык, используемый на реальном уровне домена, в конечном итоге становится довольно лаконичным, очевидным и читаемым.
Принимая во внимание форму, которую я видел в большинстве корпоративных программ, на практике DDD может звучать как серебряная пуля, потому что большинство корпоративных программ имеет такое плохое разделение проблем, что его практически невозможно проверить, и команда разработчиков живет в большом страхе перемен, потому что они не имеют ни малейшего представления о том, какими могут быть побочные эффекты якобы даже тривиальных изменений кода, тогда как должным образом разложенный уровень предметной области будет независимо проверяемым и проверяемым. Но на самом деле, DDD признает, что системы редко существуют в изоляции. DDD включает в себя шаблоны для унаследованных систем (антикоррупционный уровень, ограниченный контекст, чтобы назвать пару).
Если вы практикуете объектно-ориентированное проектирование, включая дисциплину слабой связи, и вы практикуете модульное тестирование довольно религиозно, и вы беспощадно рефакторизируете код, и вы работаете с экспертами в области доменных имен при построении вашей системы, по существу вы получите результат, который в основном, о чем говорят сторонники доменного дизайна.
В книге Эванса описано несколько конкретных шаблонов, которые в основном применимы к разработке корпоративного программного обеспечения, а некоторые - довольно универсальные принципы, но по сути DDD - это прагматичный подход к разработке программного обеспечения, который со временем может уменьшить накопление технического долга. и сделайте своих клиентов счастливее, потому что вы можете говорить на одном языке друг с другом, и предлагать более эффективные решения благодаря преимуществам лучшего понимания друг друга.
