#domain-driven-design
#domain-driven-design
Вопрос:
В Domain Driven Design как вы документируете ключевые аспекты вашей модели, чтобы ее можно было передать вашей команде и чтобы ее можно было разрабатывать с течением времени?
Под ключевыми аспектами я подразумеваю:
вездесущий язык объединяет корневые объекты / инварианты объектов значений
Комментарии:
1. Серьезно? Все это хранится в чьей-то голове и передается из уст в уста?
2. ДА. На языках, как правило, говорят. Пропускная способность связи очень важна.
3. Возможно, вам захочется просмотреть некоторые определения здесь: domainlanguage.com/ddd/patterns/DDD_Reference_2011-01-31.pdf
Ответ №1:
В коде. И в разговорах. И на досках, и в документах, и в моделях…
Ключевыми моментами являются (1) повсеместность и (2) согласованность. Итак, если эксперт по предметной области говорит об «Оценке заявки на получение кредита», у вас должен быть код, который синтаксически и семантически соответствует этой концепции. Так что у вас может быть LoanApplication.Assess() . У вас не было бы ApplicationManager.QualifyApplication() или подобного.
Таким образом, вы бы минимально записали язык в коде. Вы также можете выбрать запись в документации и / или диаграммах. Вы также будете использовать на досках и в обсуждениях. Но во всех случаях это один и тот же язык.
hth.
Комментарии:
1. Итак, вы бы написали «словарь» для языка? Я бы предположил, что, когда у вас есть несколько экспертов по предметной области, они не будут использовать одни и те же слова для обозначения вещей. Кроме того, у вас не было бы всех ваших разработчиков и экспертов по предметной области на каждом собрании, так как же вы поддерживаете эту согласованность?
2. Идея повсеместного языка заключается в том, что вы разрабатываете общий язык, чтобы все использовали общий словарь для домена. Если эксперты домена используют разные слова для обозначения вещей, это проблема, которую они должны попытаться решить.
3. Twisted: это может произойти и происходит. Как говорит @DonRoby, частью процесса является согласование конкретных значений терминов. Это требует дисциплины на всех фронтах; для экспертов по предметной области это означает быть более точным, чем это часто бывает. Например, различение между «типами» и «экземплярами» вещей: например, книга «Domain Driven Design» и конкретная копия этой книги. Это не одно и то же. но в обычном разговоре оба часто упоминаются просто как «книга по дизайну, управляемая доменом». Ясность, которую вы имеете в виду, является частью разработки этого повсеместного языка.
4. Итак, когда вы соглашаетесь «конкретно, что означает термин», не находите ли вы, что вам нужно где-то записать согласованное значение, чтобы мы поддерживали согласованность и не забывали, что было согласовано (что звучит трудоемко) или просто использует его достаточно?
5. Немного того и другого. Мне нравится, когда определения записываются лично. Вики может быть хорошим способом сделать это, поскольку она поощряет всех к участию. Но главное — использовать язык последовательно и постоянно, тогда он становится частью проекта «днк».