Реконструкція в дизайні, керованому доменом [закрито]

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

Я борюся з ідеєю постійно рефакторингу.

Я знаю, що рефакторинг - це необхідність у будь-якому проекті, і це неминуче відбуватиметься в міру зміни програмного забезпечення. Однак, на мій досвід, рефакторинг відбувається тоді, коли потреби групи розробників змінюються, а не як розуміння домену змінюється ("рефакторинг на більш глибоке розуміння", як називає Еванс). Мене найбільше хвилює прорив у розумінні доменної моделі. Я розумію, що вносяться невеликі зміни, але що робити, якщо потрібна велика зміна моделі?

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

На щастя, SCRUM надає себе на рефакторинг. Ітеративний характер SCRUM дозволяє легко створити невеликий шматок і змінити його. Але з часом цей шматок стане більшим, і що, якщо у вас прорив після цього фрагмента настільки великий, що змінити його буде занадто складно?

Хтось працював над проектом, який використовував дизайн, орієнтований на домен? Якщо так, то було б чудово ознайомитись із цим. Я особливо хотів би почути кілька історій успіху, оскільки DDD здається дуже важким отримати правильний результат.

Дякую!

Я деякий час був великим шанувальником DDD (із захисною сіткою тестових рамок і без неї).

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

Що стосується цього: в одному випадку я взяв участь у 3- місячному капітальному рефакторингу через «прорив» у розумінні доменної моделі. Це вимагало тестів для перевірки поточної поведінки, тестів для перевірки очікуваної поведінки та змін коду виклику. Переваги були значними, але вони дозволили бізнесу зробити ще багато речей, які потрібно було зробити раніше, але просто не змогли. По суті, рефакторинг був по суті "особливістю".

Рефакторинг в дизайні, керованому доменом, я думаю, що це спричинено потребою, а не "приємним" рефактором. Як тільки ви виявите неправильну модель домену, код / ​​система не представляє реальної проблеми світу.

Безумовно, ми нещодавно працювали над застосуванням розумної складності домену. Це була система виставлення рахунків / контрактів, і ми запроваджували новий тип ставки. Ми використовували спритний процес, 2 тижні розписки, щоб бути точними.

Спочатку ми визначили в моделі, що 2 ставки були повністю відокремленими і не мали жодного відношення, крім контракту. Однак, коли ми закінчили більше історій, ми зрозуміли, що вони насправді були однаковими, особливо коли ми почали обробляти нову ставку як стару, просто для того, щоб вона працювала. Це був перший попереджувальний знак.

Щоб скоротити історію, нам вдалося отримати 90% історій, зроблених за допомогою неправильної моделі, але ми дійшли до того, що в кожній частині коду ми або загортали нову ставку як стару, та / або створення, якщо newRate else oldRATE ВСЕ де. Ми стукали головою об погомонену цегляну стіну. Ми проходили на півдорозі через цю частину проекту і знали, що час завершення буде експоненціальним або нездійсненним при неправильній моделі домену. Тож ми кусаємо кулю, ділимо історію на вісім інших історій і рефакторуємо Модель домену.

Коли ми завершили проект, ми з глибокого погляду зрозуміли, що це правильно зробити, і це було ТІЛЬКО, що потрібно зробити, щоб його правильно.

Чи знадобився час? Так, але якби ми цього не зробили, це зайняло б більше часу. Чи правильно це було зроблено? Ну, як не дивно, ми тоді не знали про DDD, але незабаром після того, як ми відвідали семінар DDD від Еріка Еванса, і все, що я та мої колеги могли зробити, це кинути шлях. Я думаю, якби ми знали DDD, ми б забрали рефактор набагато раніше, тим самим заощадивши більше часу.

Якщо ви маєте щось не так у Моделі домену, важливо це виправити. На моєму досвіді ми трохи пропустили те, як модель домену підключається до різних об'єктів, коли ми реалізували деякі з них.

Це призвело до того, що люди звикли моделювати так, як це не було придушено, і, таким чином, ламають інші частини моделі, щоб спробувати "примусити її працювати".

Як тільки ви зрозумієте, що в моделі домену щось не так, змініть це якомога швидше. Чим довше пройде, перш ніж переробляти його, тим важче буде змінитися стосовно користувачів, які ментальні моделі тепер адаптовані.

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

Питання: "чи потрібна буде ця еволюція?". У домені Core (область, яка робить ділову різницю) відповідь "Так!". Тому що це зілля тієї сфери, якою займається бізнес, і тієї, яка змінить значення для зацікавлених сторін. Це місце, де ви хочете зберегти свій код у ідеальній формі, готовий здійснити наступну вимогу з мінімальними зусиллями, завдяки гнучкості вашої доменної моделі.

Однак це буде коштувати дорого, якщо застосувати його до всього коду програми. Сфери, які не такі важливі для бізнесу ( підтримуючі або загальні субдомени в DDD lingo), можуть вимагати менш складний підхід, ніж той, який зарезервований для ядра.