Я слышал о разработке, управляемой доменом, от разработчика в этой области. Он говорил об этом так, словно речь шла о серебряной пуле с меняющимися требованиями.
Я читаю вики . Все еще не слишком ясно. Что такое "3D" в практическом плане? Разве это удивительно, что теперь UML-диаграммы просто устарели?
Ответы:
Ну, во-первых, я не думаю, что статья в Википедии, на которую вы ссылаетесь, очень хороша, в основном потому, что она ссылается на кучу вещей, которые являются вспомогательными только для Domain Driven Design, и мало что делает для ознакомления кого-либо с практикой.
Но, как человек, который воспринял доменно-управляемый дизайн близко к сердцу (что обычно стоит в DDD, а не в 3D, для чего это стоит), я всегда чувствовал, что основы DDD очевидны, если вы читаете так много, как первая глава Эрика Книга Эванса. Но это набор шаблонов и практик, поэтому не так просто дать краткое изложение из трех предложений о том, что это такое и каковы преимущества, не вдаваясь в некоторые подробности. Какие детали резонируют с каким-то одним человеком, тоже может сильно отличаться; вполне вероятно, что 10 лет назад я бы вообще не увидел в этом смысла.
DDD это не серебряная пуля. Когда все сделано разумно, речь идет о мастерском подходе к созданию программного обеспечения и признании необходимости уменьшить когнитивные трения между командами разработчиков и предприятиями, для которых они создают программное обеспечение. Одним из наиболее важных методов является создание слоя, в котором словарь домена, используемый командой разработчиков программного обеспечения и бизнес-группой, максимально соответствует друг другу. Вы строите этот слой итеративно, когда понимаете бизнес-проблему, которую пытаетесь решить. Когда бизнес-логика разумно закодирована на этом уровне, изолирована от всех запутанных зависимостей, которые обычно имеют корпоративные приложения, путем разделения взаимодействий с этими системами на интерфейсы, язык, используемый на реальном уровне домена, в конечном итоге становится довольно лаконичным, очевидным и читаемым.
Принимая во внимание форму, которую я видел в большинстве корпоративных программ, на практике DDD может звучать как серебряная пуля, потому что большинство корпоративных программ имеет такое плохое разделение проблем, что его практически невозможно проверить, и команда разработчиков живет в большом страхе перемен, потому что они не имеют ни малейшего представления о том, какими могут быть побочные эффекты якобы даже тривиальных изменений кода, тогда как должным образом разложенный уровень предметной области будет независимо проверяемым и проверяемым. Но на самом деле, DDD признает, что системы редко существуют в изоляции. DDD включает в себя шаблоны для унаследованных систем (антикоррупционный уровень, ограниченный контекст, чтобы назвать пару).
Если вы практикуете объектно-ориентированное проектирование, включая дисциплину слабой связи, и вы практикуете модульное тестирование довольно религиозно, и вы беспощадно рефакторизируете код, и вы работаете с экспертами в области доменных имен при построении вашей системы, по существу вы получите результат, который в основном, о чем говорят сторонники доменного дизайна.
В книге Эванса описано несколько конкретных шаблонов, которые в основном применимы к разработке корпоративного программного обеспечения, а некоторые - довольно универсальные принципы, но по сути DDD - это прагматичный подход к разработке программного обеспечения, который со временем может уменьшить накопление технического долга. и сделайте своих клиентов счастливее, потому что вы можете говорить на одном языке друг с другом, и предлагать более эффективные решения благодаря преимуществам лучшего понимания друг друга.
Описание высокого уровня может быть -
Смоделируйте свои классы, чтобы отразить структуры данных и поведение вашей проблемной области.
Это позволяет сопоставить изменения в проблемном домене непосредственно с изменениями в коде, поэтому его будет проще обновлять по мере развития проблемного домена.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я добавил этот ответ после того, как этот вопрос был отмечен как дубликат. Я не согласен, но мы здесь. :-)
Домен-управляемый дизайн направлен на разработку программного обеспечения в областях высокой стоимости / высокой сложности.
Это превращается в другой подход к созданию корпоративного программного обеспечения: слишком много обучения требуется, и наиболее важным последствием является то, что вы не получите правильное решение с первого взгляда.
Или сочетание обоих.
В обоих случаях вам понадобятся хорошие основы программного обеспечения для частой перезаписи программного обеспечения. По этой причине в книге сделан акцент на заданном наборе шаблонов модели предметной области: они были наиболее разумной комбинацией в 2004 году.
Однако ООП и тактическая схема - не самое главное. Техническое мастерство необходимо для того, чтобы создавать отличное программное обеспечение эволюционным путем. Но это только один ингредиент рецепта. Другие?