Як поєднувати суворі TDD та DDD?

TDD - це розробка коду, керуючись тестами.
Таким чином, типові шари зазвичай не будуються вперед; вони повинні злегка з'являтися через кроки рефакторингу.

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

Як почати кодувати частину проекту DDD з нуля, як поводитися?
Чи слід чітко дозволити дизайну виходити з тестів, маючи на увазі відсутність роз'єднання проблем (без шарів) та рефактора для того, щоб відповідати технічним моделям DDD?

Або я повинен створити ці порожні шари (додаток, об'єкти / послуги домену, інфраструктура) і дозволити TDD вміщуватися в кожному з них незалежно (використовуючи макети для ізоляції між шарами)?

Обов’язково перегляньте останні коментарі дядька Боба щодо ролі дизайну в TDD .

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

Уді Дахан: "Боже, як я ненавиджу нашарування". Він витрачає деякий час, обговорюючи це у своїй розмові CQRS - але по-різному (нашарування починається з 18m30s)

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

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

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

Проблеми із застосуванням десь посередині; вони, як правило, стабільні, тому користувачам не потрібно вивчати нову програму з кожним випуском.

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

Тим часом, CTO хоче версію програми, яка працює на його телефоні; щойно почув від хлопця генеральний директор, що публікація API - це велика річ.

Також команда з продажу використовує іншу модель, тому дайте нам те саме додаток, з іншою моделлю. О, але ми багато подорожуємо, тому наша версія повинна працювати, коли ми не в режимі офлайн і синхронізуємось пізніше ...

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

Тестова розробка (TDD) - це не дизайн. Це вимога, яка впливає на ваш дизайн. Так само, як якщо б від вас вимагали безпеку ниток, це не дизайн. Знову ж таки, це вимога, яка впливає на ваш дизайн.

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

Одна приємна річ, що стосується тест-лайна, це те, що це ремонтопридатне лайно, тому для деяких людей це досить добре. Ми будемо фантазувати лише тоді, коли буде потрібно. Інші ненавидять це і звинувачують у цьому TDD. Ні. Це твоя справа.

Дизайн, керований доменом (DDD) - це те, що ви робите перед циклом червоного зеленого рефактора TDD.

DDD - це намагання створити та зберегти простір у коді, де експерт із домену, який значною мірою не звертає уваги на деталі системи, може зрозуміти, як керувати системою. Це робиться шляхом абстрагування та моделювання проблемної області звичним способом.

Система DDD може мати архітектуру, яка виглядає приблизно так:

Ця архітектура DDD має багато назв: Очистити , Лук , Шестикутник тощо

Ось відключення, яке я бачу у багатьох людей, коли вони дивляться на цю конструкцію. Це не конкретно. Я можу слідувати цій конструкції і ніколи не писав нічого, що ви бачите на схемі. Я бачу, як інші наполягають на тому, що повинен бути об'єкт використання або клас сутностей. Що це таке - це набір правил, які розповідають, з ким можна спілкуватися та як.

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

Ще нечітко? Подивіться на діаграму Controler- Use Case Interactor- Presenterу правому нижньому куті. Ось три конкретні речі, що спілкуються між собою. Звичайно, це DDD, але як тут додати TDD? Просто знущайтеся з конкретних речей. Ведучий повинен отримувати інформацію. PresenterMockКлас був би хороший спосіб перевірити , що це те , чого ви очікували отримати. Передайте і драйв , як якщо б ви були і у вас є хороший спосіб для модульного тестування , так як насмішка скаже вам , якщо він отримав те , що ви очікували отримати.Use Case InteractorPresenterMockUse Case InteractorControllerUse Case Interactor

Добре подивіться на це. TDD задоволений, і нам не довелося піти з нашим дизайном DDD. Як це сталося? Ми почали з добре відокремленого дизайну.

Якщо ви використовуєте TDD для приводу дизайну (не просто D evelopment), ви отримуєте дизайн, який відображає зусилля, які ви вкладаєте в нього. Якщо це тобі хочеться прекрасного. Але це ніколи не було для чого TDD. Те, що в кінцевому підсумку не вистачає, звичайно, не винна TDD.

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

TDD страхує, що ваш код має всі необхідні тестові випадки, написані паралельно розробці. Це не повинно впливати на дизайн високого рівня. Подумайте про це більше в роботі траншей.

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

Це обидва дрібних пояснення двох потужних методологій програмування. Але наприкінці дня вони дійсно виконують дві дуже різні речі.

Почніть з відображення мови DDD та контексту, а потім, коли ви переходите до написання коду, почніть практику TDD. Але практика TDD не повинна впливати на дизайн високого рівня, але вона повинна гарантувати, що речі можна перевірити. Тут є трохи застереження.

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

DDD - це про розробку програмного забезпечення.
TDD - про дизайн коду.

У DDD "модель" являє собою абстракцію домену, всі знання від експерта з домену.

Ми могли б використовувати TDD для початкової моделі дизайну програмного забезпечення. У домені є ділові правила та моделі домену, згідно з якими тест (перший) повинен бути зеленим.

Насправді ми можемо кодувати тести, розробивши модель, керовану доменом.
Ця книга "Зростаюче об'єктно-орієнтоване програмне забезпечення, керуючись тестами" Посилання на купівлю
Візьміть такий підхід із крокуючим скелетом , шестикутною архітектурою та TDD.

Джерело: DDD швидко - InfoQ

Чи слід чітко дозволити дизайну виходити з тестів

Ні. (Управління доменом) Дизайн за визначенням повинен виходити з доменних вимог. Це погана ідея, щоб дозволити що-небудь інше керувати вашим дизайном, будь то тестовий набір, схема бази даних чи ... (буде продовжено)

Або я повинен створити ці порожні шари (додаток, об'єкти / сервіси домена, інфраструктура) і дозволити TDD вміщуватися в кожному з них незалежно

... .

Що стосується DDD, OOP не вистачає висловлюючих вимог у читаній для людини формі, тобто щось, що було б більш-менш зрозуміло для непрограміста. Строго набрані мови FP роблять кращу роботу. Рекомендую прочитати книгу про DDD, використовуючи функціональне програмування "Моделювання доменів, зроблене функціональним" Скотта Wlaschin

https://pragprog.com/book/swdddf/domain-modeling-made-functional

Вам не доведеться використовувати мову FP, щоб запозичити з них деякі ідеї (не всі вони, на жаль,), але якщо ви насправді прочитаєте її, то, ймовірно, захочете використовувати функціональну мову.

Він також відповість на ваше запитання про те, як TDD вписується у зображення DDD. У двох словах, коли вимоги кодуються у функціональному стилі, це виключає необхідність у величезній кількості тестових одиниць, оскільки це робить більшість недійсних станів та сценаріїв непредставними / неможливими для складання. Звичайно, в проекті FP все ще є місце для автоматизованого тестування, але тести жодним чином не призведуть до важливих дизайнерських рішень.

Щоб зробити повне коло, повернемось до заголовкового питання, тобто "Як поєднувати суворі TDD та DDD?". Відповідь однозначна: нічого поєднувати / конфліктувати інтереси немає. Дизайн відповідно до вимог, розробляйте відповідно до дизайну (спочатку написавши тести, якщо ви дійсно хочете робити TDD)