Эта статья по сути является вольным пересказом фрагмента книги Рика Вэнса «Domain-Driven Design», в которой он обсуждает отдельные пути и ограниченный контекст. Допустим, имеется следующая ситуация: над одним и тем же проектом работают несколько групп разработчиков, но решают разные задачи.
Например, проект — конструктор микросхем, и первая команда реализует функционал вызова микросхемы, а вторая — расчета стоимости микросхемы.
Вопрос: что лучше сделать - 1) позволить обеим командам "воровать в собственном соку", получив на выходе два модуля, код которых практически нигде не пересекается, или 2) наладить связь между двумя командами , заставить их работать вместе и получить монолитную систему с одним выходом? На этот вопрос не существует универсального ответа («да» или «нет»), и аналогия со слоном и мудрецами поможет нам найти ответ в этой ситуации.
Здесь слон — сложная предметная область, а умники — программисты.
Шесть седых мудрецов Они приехали из разных стран.
К сожалению, все были слепы, Но он блистал интеллектом.
Они исследуют слона Они пришли в Индостан.
Один погладил слона по боку.
Полностью этим доволен Он сказал: «Правда сейчас Видно при дневном свете: То, что мы называем слоном, это? Сплошная стена! И взял в руки третий ствол И он крикнул: «Друзья! Наш вопрос гораздо проще, Я в этом уверен! Этот слон – живое существо, А именно змея! Четвертый мудрец схватил Одна из ног слона И сказал он важно: «Это ствол, Картина мне ясна! Слон – дерево, которое зацветет, Когда придет весна! Тем временем шестой из них Добрался до хвоста.
И он засмеялся, потому что Как проста истина.
«Ваш слон — это веревка.
Если не Зашейте мне рот!» И, как известно, мудрецы Имеет упрямый характер.
Затеяв спор, они дошли до Почти до репрессий.
Но никто не знал правды Хотя в чём-то он был прав.
Если подпрограмма команды программистов (мудрецов) взаимодействует с определенной частью проблемной области (ногами слона), то ей не обязательно знать всю проблемную область (слона).
В то же время, если упростить эту часть предметной области, отбросив все лишнее (превратив ноги слона в деревья), то они получат код, понятный тому, кто плохо знаком с предметной областью ( не знает, что такое слон).
Кроме того, если предметная область слишком сложна, то при попытке объять необъятное внутренним взором программист впадет в когнитивный ступор и скорость разработки упадет на порядок.
Но, с другой стороны, такой подход усложняет взаимодействие между отдельными частями программы.
Давайте сравним оба подхода.
Итак, преимущества больших контекстов (монолитных систем): • различные пользовательские операции взаимосвязаны более плавно и естественно, когда как можно больше различных объектов и операций охватывается одной единой моделью; • легче понять одну последовательную модель, чем две разные, и уровень сопоставления между ними; • перевод между двумя моделями может быть затруднен (если не невозможен); • Общий язык способствует четкому общению внутри команды разработчиков.
Преимущества небольших контекстов (много разнородных модулей): • сокращаются затраты на связь между разработчиками (так как общения становится меньше); • НЕПРЕРЫВНУЮ ИНТЕГРАЦИЯ легче реализовать в небольших группах с небольшой базой кода; • в более широком контексте могут потребоваться более общие и абстрактные модели, требующие редких навыков разработчика; • Модели меньшего размера могут удовлетворять особые потребности или соответствовать жаргону специализированных групп пользователей, а также узкоспециализированным диалектам ВЕЗДЕСУЩЕГО ЯЗЫКА.
Следует также отметить, что теоретически змея, деревья и веревка могли эволюционировать в слона.
Если, например, изменится спецификация программы и окажется, что слон умеет ходить, то деревья вполне могут превратиться в ноги.
Однако не все так просто.
Идеализируется случай, когда части предметной области нигде не пересекаются; на практике, скорее всего, это не так.
Допустим, две команды программистов работают с хоботом слона, но первую команду интересует тот факт, что хобот имеет свойства живого существа, а их хобот — змеи, а вторую команду интересует способность хобот для разбрызгивания воды, а их хобот — это водяной шланг.
Со временем по чистой случайности обе команды разработчиков поняли, что змея первой команды и шланг второй описывают одно и то же явление, после чего вторая команда решила заменить шланг змеей, плюющейся водой.
А для этого потребуется две недели рефакторинга.
По моему опыту, никто не даст вам две недели на что-то неизвестное, если только проект не начал проседать под тяжестью технического долга, но и тогда за эти две недели вы будете решать более насущные проблемы, чем превращать шланг в плюющаяся змея.
Таким образом, в реалиях российского развития, если вы изначально не начнете двигаться к монолитной модели, то перейти на нее вам будет практически невозможно, а отход от монолитности не является проблемой.
Если вы выбрали путь множества несвязанных друг с другом модулей, то помните следующую пословицу: «Если три команды программистов разработают компилятор, то на выходе будет трехпроходный алгоритм».
Остерегайтесь этого.
Архитектура программы должна отражать предметную область, а не внутреннюю структуру вашей компании! P.S. Данная статья родилась как ответ на небольшой холивар в Эта статья .
Если вас интересуют примеры из реальной жизни, рекомендую прочитать статью Грубое нарушение принципа многоуровневости .
Теги: #программирование #дизайн #ddd #ограниченный контекст #Раздельные пути.
#программирование #Анализ и проектирование систем #проектирование и рефакторинг #Промышленное программирование
-
Аллигаторы
19 Oct, 24 -
Game Boy Pocket: Краткий Обзор + Потроха
19 Oct, 24 -
Обзор Китайского Клона Htc Eris
19 Oct, 24
