Що таке дизайн, керований доменом (DDD)? [зачинено]

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

По-перше, якщо ви не знаєте, що вам це потрібно, можливо, він вам не потрібен. Якщо ви не розпізнаєте проблеми, які вирішує DDD, можливо, у вас немає цих проблем. Навіть прихильники DDD часто зазначають, що DDD призначений лише для великих (> 6 місяців) проектів.

Якщо припустити, що ви все ще читаєте на даний момент, я захоплююсь DDD таким:

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

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

Концепції, описані UL, ляжуть в основу вашого об'єктно-орієнтованого дизайну. DDD надає чіткі вказівки щодо того, як ваші об’єкти повинні взаємодіяти, і допомагає розділити об'єкти на наступні категорії:

• Об'єкти значення, які представляють значення, яке може мати підрозділи (наприклад, дата може мати день, місяць та рік)
• Суб'єкти, які є об'єктами, що мають ідентичність . Наприклад, кожен об’єкт Замовника має свою особу, тому ми знаємо, що два клієнти з однаковою назвою - не той самий клієнт
• Сукупні корені - це об'єкти, якими володіють інші об'єкти. Це складна концепція і працює на основі того, що є деякі об'єкти, які не мають сенсу, якщо вони не мають власника. Наприклад, об’єкт "Рядок замовлення" не має сенсу без належності "Порядку", тому ми говоримо, що Порядок є сукупним коренем, а об'єктами Лінії замовлення можна керувати лише методами в об'єкті Порядок

DDD також рекомендує кілька моделей:

• Сховище , зразок стійкості (збереження та завантаження даних, як правило, до / з бази даних)
• Фабрика , зразок для створення об’єктів
• Сервіс - зразок для створення об’єктів, що маніпулюють вашими основними об’єктами домену, не входячи в самий домен

Тепер, на даний момент, я повинен сказати, що якщо ви ще не чули ні про що з цього, ви не повинні намагатися використовувати DDD в будь-якому проекті, на який у вас є термін. Перш ніж спробувати DDD, ви повинні ознайомитись із моделями дизайну та моделями дизайну підприємства . Знаючи це, DDD набагато простіше зрозуміти. І, як згадувалося вище, доступне безкоштовне введення в DDD, доступне в InfoQ (де ви також можете знайти розмови про DDD).

Візьміть StackOverflow як приклад. Замість того, щоб починати розробляти деякі веб-форми, ви спершу зосереджуєтесь на тому, щоб робити об’єктно-орієнтоване моделювання об'єктів у межах вашої проблемної області, наприклад користувачів, запитань, відповідей, голосів, коментарів тощо. Оскільки дизайн визначається деталями проблеми Домен називається дизайном, керованим доменом .

Більше ви можете прочитати в книзі Еріка Еванса .