Рефакторинг в доменном дизайне [закрыто]

Я только начал работать над проектом, и мы используем управляемый доменом проект (как определил Эрик Эванс в « Управляемом доменом проектировании: решение сложных задач в основе программного обеспечения» . Я считаю, что наш проект, безусловно, является кандидатом на этот проект). шаблон, как Эванс описывает его в своей книге.

Я борюсь с идеей постоянного рефакторинга.

Я знаю, что рефакторинг необходим в любом проекте и неизбежно произойдет при изменении программного обеспечения. Однако, по моему опыту, рефакторинг происходит, когда меняются потребности команды разработчиков, а не меняется понимание домена («рефакторинг для лучшего понимания», как называет его Эванс). Меня больше всего волнуют прорывы в понимании модели предметной области. Я понимаю, что нужно вносить небольшие изменения, но что, если в модели необходимо большое изменение?

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

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

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

Спасибо!

Некоторое время я был большим поклонником DDD (с сеткой безопасности тестовой среды и без нее).

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

Что касается этого: в одном случае я участвовал в трехмесячном рефакторинге из-за «прорыва» в понимании модели предметной области. Требуются тесты для проверки текущего поведения, тесты для проверки ожидаемого поведения и изменений в вызывающем коде. Однако выгоды были значительными и позволили бизнесу сделать гораздо больше вещей, которые он должен был сделать раньше, но просто не смог. По сути, рефакторинг был, по сути, «особенностью».

Рефакторинг в доменно-управляемом дизайне, я думаю, обусловлен необходимостью, а не «хорошим» рефакторингом. Как только вы идентифицируете неправильную модель предметной области, код / ​​система не представляет реальной проблемы.

Например, недавно мы работали над приложением разумной доменной сложности. Это была система биллинга / контракта, и мы вводили новый тип тарифа. Мы использовали гибкий процесс, если быть точным, двухнедельную суету.

Первоначально мы определили в модели, что 2 ставки были полностью разделены и не имели никакого отношения, кроме как через Контракт. Однако по мере того, как мы заканчивали больше историй, мы осознали, что они на самом деле были одинаковыми, особенно когда мы начали использовать новый курс как старый, чтобы заставить его работать. Это был первый предупреждающий знак.

Короче говоря, мы смогли сделать 90% историй, выполненных с неверной моделью, но мы дошли до того, что в каждой части кода мы либо оборачивали новый Rate как старый, и / или создание, если newRate еще oldRate КАЖДОЕ где. Мы бились головой об общеизвестную кирпичную стену. Мы были на полпути через эту часть проекта, и знали, что время для завершения будет экспоненциальным или неработающим при неправильной модели предметной области. Таким образом, мы укусили пулю, разделили историю на восемь других историй и реорганизовали модель предметной области.

Когда мы завершили проект, мы знали, что это было правильно, и ЕДИНСТВЕННАЯ вещь, чтобы сделать это правильно.

Это заняло время? Да, но если бы мы этого не делали, это заняло бы больше времени. Правильно ли было сделано DDD? Что ж, как ни странно, в то время мы не знали о DDD, но вскоре после того, как мы посетили семинар DDD Эрика Эванса, и все, что я и мои коллеги могли сделать, это кивнуть. Я думаю, если бы мы знали DDD, мы бы забрали рефакторинг гораздо раньше, что позволило бы сэкономить больше времени.

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

Это привело к тому, что люди привыкли моделировать так, как это не было предназначено, и таким образом ломали другие части модели, пытаясь «заставить ее работать».

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

Для некоторых частей кода непрерывный рефакторинг является излишним. Для некоторой другой части кода (в DDD, так называемый Core Domain ) это необходимо. Понимание того, что код не такой, каким он должен быть, создает дополнительную когнитивную нагрузку на разработчика (различие между нашим пониманием предметной области и текущей реализацией), что сделает дальнейшее развитие более трудным и / или дорогим.

Вопрос в том, «понадобится ли эта эволюция?». В Базовом Домене (область, которая имеет значение для бизнеса) ответ «Да!». Потому что это зелье домена, о котором бизнес больше заботится и которое будет иметь значение для заинтересованных сторон. Это место, где вы хотите поддерживать свой код в идеальной форме, готовым к выполнению следующего требования с минимальными усилиями благодаря гибкости вашей доменной модели.

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