Монолітна система VS безліч самостійних модулів на прикладі притчі про слона і мудреців

Дана стаття являє собою в основному вільний переказ фрагмента книги Еріка Еванса «Предметно-орієнтоване проектування», в якому він розмірковує про Separate Ways і Bounded Context.

Припустимо, є наступна ситуація: кілька груп розробників працюють над одним проектом, але вирішують різні завдання. Наприклад, проект являє собою конструктор мікросхем, і перша команда реалізує функціональність прозванивания мікросхеми, а друга — розрахунком собівартості мікросхеми. Питання: як краще вчинити — 1)дозволити обом командам «варитися у власному соку», отримавши на виході два модуля, код яких практично ніде не перетинається, або ж 2)налагодити комунікацію між двома командами, змусити їх працювати спільно і отримати на виході єдину монолітну систему? На це питання не існує універсальної відповіді («так» або «ні») і знайти відповідь в цій ситуації нам допоможе аналогія зі слоном і мудрецями.




Тут слон — складна предметна область, а мудреці — програмісти.

Шість сивочолих мудрих
Зійшлися з різних країн.
До нещастя, кожен був незряч,
Зате відзначався розумом.
Вони дослідити слона
З'явилися в Індостан.
Один погладив пліч слона.
Задоволений тим сповна,
Сказав він: «Істина тепер
Як божий день видно:
Предмет, що ми звемо слоном,
Прямовисна стіна!»
А третій хобот у руки взяв
І закричав: «Друзі!
Набагато простіше наше запитання,
Впевнений у цьому!
Цей слон — жива істота,
А саме змія!»
Мудрець четвертий обхопив
Одну з ніг слона
І важливо мовив: «Це стовбур,
Картина мені зрозуміла!
Слон — дерево, що зацвіте,
Коли прийде весна!»
Тим часом шостий з них
Добрався до хвоста.
І розсміявся від того,
Як істина проста.
«Ваш слон — мотузка. Якщо ж немає
Зашийте мені вуста!»
А як відомо, мудрецям
Притаманний впертий характер.
Суперечка розв'язавши, вони дійшли
Ледь ль не до розправ.
Але правди ні один не знав,
Хоча був у чомусь правий.

Якщо підпрограма команди програмістів (мудреців) взаємодіє з конкретною частиною предметної області (ногами слона), то їй немає необхідності знати всю предметну область (слона). У той же час, якщо вони спростять цю частину предметної області, відкинувши все зайве (перетворивши ноги слона в дерева), то вони отримають такий код, зрозуміти який зможе і той, хто погано знайомий з предметною областю (не знає що таке слон). Крім того, якщо предметна область занадто складна, то при спробі охопити внутрішнім поглядом неосяжне, програміст впаде в когнітивний ступор і швидкість розробки впаде на порядок. Але, з іншого боку, при такому підході ускладнюється взаємодія між окремими частинами програми.

Порівняємо між собою обидва підходи. Отже, переваги великих контекстів (монолітних систем):
• різні користувальницькі операції пов'язані між собою більш плавно і природно, коли якомога більше різних об'єктів і операцій охоплені однією уніфікованою моделлю;
• легше зрозуміти одну зв'язну модель, ніж дві різні і рівень відображення між ними;
• трансляція між двома моделями може виявитися складним (а то й неможливим);
• спільну мову стимулює чітке взаємодія в групі розробників.

Переваги малих контекстів (безліч різнорідних модулів):
• знижуються витрати комунікації між розробниками (т. к. самих комунікацій менше);
• БЕЗПЕРЕРВНУ ІНТЕГРАЦІЮ (CONTINUOUS INTEGRATION) простіше виконувати в малих групах з невеликими базами коду;
• у великих контекстах можуть знадобитися більш універсальні і абстрактні моделі, що вимагають рідко зустрічається кваліфікації розробників;
• невеликі моделі можуть обслуговувати спеціальні потреби або відповідати жаргону спеціалізованих груп користувачів, а також вузькоспеціальних діалектів ЄДИНОГО МОВИ (UBIQUITOUS LANGUAGE).

Також слід зазначити, що теоретично змія, дерева і мотузка можуть еволюціонувати в слона. Якщо, наприклад, специфікація програми зміниться і з'ясується, що слон може ходити, то дерева цілком можуть перетворитися на ноги. Однак не все так просто. Випадок, коли частини предметної області ніде не перетинаються — ідеалізовано, на практиці найімовірніше це не так. Припустимо, дві команди програмістів працюють з хоботом слона, проте першу команду цікавить те, що хобот має властивості живої істоти, і у них хобот — змія, а другу команду цікавить здатність хобота вихлюпувати воду, і у них хобот — шланг для води. З часом, по чистій випадковості, обидві команди розробників зрозуміли, що змія першої команди і шланг другий описують одне і теж явище, після чого друга команда вирішила замінити шланг на плюющуюся водою змію. А для цього потрібно двотижневий рефакторинг. По своєму досвіду скажу, що ніхто не дасть вам займатися два тижні незрозуміло чим, якщо проект не почав йти на дно під вантажем технічних боргів, але навіть у такому випадку ці два тижні ви будете вирішувати більш нагальні проблеми, аніж перетворення шланга в плюющуюся змію. Таким чином, в реаліях російської розробки, якщо ви спочатку не почнете рухатися в напрямку монолітної моделі, то потім перемкнутися на неї вам буде практично неможливо, в той час як піти від монолітності не становить проблем.
Якщо ж ви обрали шлях багатьох не взаємопов'язаних модулів, то пам'ятайте наступну прислів'я: «Якщо три команди програмістів розробляють компілятор, то на виході вони отримають трехпроходный алгоритм». Остерігайтеся цього. Архітектура програми повинна відображати предметну область, а не внутрішнє пристрій вашої компанії!

P. S. Дана стаття народилась як відповідь на невеликий холівар цієї статті.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.