Как заставить непрограммистов понять модель предметной области - PullRequest
0 голосов
/ 02 октября 2018

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

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

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

Единственный выход, о котором я мог подумать,поддерживать правильное ведение документов / графиков / графиков для каждого изменения и всегда отражать базовую модель.Однако я думаю, что это огромный вызов для любого нетривиального проекта.И очень трудно решить, сколько деталей нужно включить в документ.

Есть ли какая-либо лучшая практика, из которой я мог бы извлечь уроки, чтобы модель предметной области была понятна людям, а также проста?развиваться с продуктом?

Ответы [ 2 ]

0 голосов
/ 02 октября 2018

Использование управляемой поведением разработки (BDD) .

BDD похож на TDD.Но BDD всегда фокусируется на тестировании домена поведения , и тесты определяются с использованием Ubiquitous Language домена.Все истории / особенности / сценарии могут быть написаны в структурированной, удобочитаемой для человека форме ( как эта )

И поскольку тесты тесно связаны с вашим кодом, они должны оставатьсясинхронно (при условии, что ваша команда дисциплинирована в поддержании актуальности тестов).

По моему опыту, это предлагает наиболее экономичное решение для выявления современных правил домена в умеренной степени.читаемый формат.

0 голосов
/ 02 октября 2018

Наиболее важной стратегией, которая исходит от DDD, являются Ограниченные контексты .Это соответствует (суб) доменам в бизнесе.В идеале они должны отображаться один в один.Итак, первый шаг, который необходимо сделать, - это четко определить (под) домены;это тоже самое сложное.

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

https://www.infoq.com/articles/ddd-contextmapping

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

Для каждого (под) домена вы можете вести список основных бизнес-правил.Программное обеспечение для управления задачами (например, Jira) может быть единственным источником правды для них.

...