Важность объектной модели в доменном дизайне

Question

Наша команда довольно нова для дизайна, управляемого доменом. У нас есть новый проект, который только что перешел от этапа проектирования к фазе кодирования. На этапе проектирования некоторые члены команды создали модели UML в Visio, а другие только начали кодирование. Кроме того, с давлением выпусков сборки многие из наших моделей быстро устаревают.

Важно ли обновлять объектные модели? Важно ли иметь их для всех/большинства подсистем?

Answer 1

Я думаю, что ответ «это зависит», нет?

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

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

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

Answer 2

Лучшая документация, которую вы имеете для своего кода (и моделей), это схема кода и базы данных. Разработка моделей вне кода может иметь определенную ценность в понимании проблемы, но, как вы обнаружили, в конечном итоге они становятся ответственностью. Если вы собираетесь использовать их вообще, вам нужно инвестировать время, чтобы поддерживать их в актуальном состоянии. Гибкая философия могла бы сказать, что инвестировать столько времени в их поддержание, сколько вы получите от них. Как правило, это не так много, поскольку код является окончательным авторитетом. Если у вас есть нормативные требования, это может быть другой случай, но я бы обычно отказался от модели, как только он был переведен в код, и регенерировал модель по мере необходимости непосредственно из кода/схемы, если вам нужен документ для его описания.

Answer 3

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

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

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

Answer 4

Любая документация ниже User Story Уровень напрямую связан с деталями реализации и, следовательно, с изменчивыми фактами (почему и как). Поэтому (как, модели) не должны поддерживаться вручную, а вместо этого генерироваться при необходимости только ради улучшения связи с разработчиками.

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

Затем сверните сгенерированную документацию снова. Это только поможет вам лучше общаться с разработчиками. Это не имеет никакой дополнительной ценности.

Только что это было сегодня: разработчик подошел ко мне с красивой диаграммой Visio, напечатанной на бумаге, выглядящей действительно красивой. Я открыл IDE и показал ему, что в исходном коде указано что-то немного отличное от документации, которую он держал в руках. Пришло время понять, что код выигрывает над документацией. Всегда.