Я чув про розробку доменів, розроблену в цьому районі. Він говорив про це так, як саме про срібну кулю до змін, що змінюються.
Я читаю вікі . Ще не надто зрозуміло. Що таке "3D" на практиці? Це насправді дивно, що тепер діаграма класів UML просто застаріла?
Відповіді:
Ну, по-перше, я не вважаю, що стаття у Вікіпедії, на яку ви посилаєтесь, дуже гарна, здебільшого тому, що вона посилається на купу речей, які є лише допоміжними засобами дизайну, керованого доменом, і мало що просвітить когось щодо практики.
Але, як хтось прийняв до душі дизайн, керований доменом (звичайно це стосується DDD, а не 3D, наскільки це варто), я завжди відчував, що основи DDD є очевидними, якщо ви читаєте так багато, як перший розділ Еріка Книга Еванса. Але це набір шаблонів та практик, тому не так просто дати короткий підсумок у 3 реченнях, що це таке та які переваги, не вдаючись до деталей. Які деталі перегукуються з будь-якою людиною, теж можуть бути дуже різними; певно, що 10 років тому я сам би цього не бачив.
DDD - це не срібна куля. Коли це зроблено розумно, мова йде про підхід, подібний до майстра, до створення програмного забезпечення та визнання необхідності зменшити когнітивне тертя між командами розвитку та бізнесом, для якого будують програмне забезпечення. Однією з найважливіших практик є створення шару, в якому лексика домену, яка використовується командою програмного забезпечення та бізнес-командою, відповідає максимально наближеному. Ви будуєте цей шар ітераційно, коли зрозумієте бізнес-проблему, яку ви намагаєтеся вирішити. Коли бізнес-логіка є чітко закодованою в цьому шарі, ізольованій від усіх звивистих залежностей, які зазвичай застосовують корпоративні програми, шляхом факторизованої взаємодії з цими системами до інтерфейсів, мова, що використовується у фактичному доменному шарі, з часом стає досить стислим, очевидним та читабельним.
Враховуючи форму, яку я бачив у більшості програмного забезпечення підприємства, на практиці DDD може здатися схожою на срібну кулю, тому що більшість програмного забезпечення підприємства має таке бідне питання, що це майже непереборно, і команда програмного забезпечення живе в великому страху перед змінами, оскільки вони не мають поняття, якими можуть бути побічні ефекти нібито навіть тривіальних змін коду, тоді як належним чином врахований доменний шар буде незалежно перевірений та перевірений. Але насправді DDD визнає, що системи рідко існують ізольовано. DDD включає схеми подолання застарілих систем (Антикорупційний рівень, обмежений контекст, щоб назвати пару).
Якщо ви практикуєте об'єктно-орієнтований дизайн, включаючи дисципліну вільного з’єднання, і ви практикуєте тестування одиниць досить релігійно, і ви нещадно кодуєте рефактор, і ви працюєте з експертами по домену, будуючи свою систему, по суті, ви отримаєте результат, який в основному, про що говорять прихильники дизайну, керованого доменом.
У книзі Еванса є декілька конкретних закономірностей, які в основному стосуються розробки програмного забезпечення для підприємств, і деякі, які є досить універсальними принципами, але, по суті, DDD - це прагматичний підхід до розробки програмного забезпечення, який може з часом зменшити накопичення технічної заборгованості, і зробіть своїх клієнтів щасливішими, оскільки ви вмієте розмовляти однаковою мовою один з одним, а також пропонуєте більш якісні рішення через переваги кращого розуміння один одного.
Опис високого рівня може бути -
Моделюйте свої класи, щоб відображати структури даних та поведінку вашої проблемної області.
Це дозволяє вам відображати зміни у вашому проблемному домені безпосередньо на зміни у вашому коді, тому оновити його слід легше в міру розвитку вашого проблемного домену.
ВІДХОДЖЕННЯ: Цю відповідь я додав після того, як це питання було позначене як дублікат. Я не згоден, але ось ми. :-)
Дизайн, керований доменом, спрямований на розробку програмного забезпечення в областях високої / високої складності.
Це перетворюється на інший підхід до створення корпоративного програмного забезпечення: тут занадто багато навчання, і найважливішим наслідком є те, що ви не знайдете правильне рішення з першого разу.
Або поєднання обох.
Обидва способи вам знадобляться хороші основи програмного забезпечення для часто переписують програмне забезпечення. Ось чому книга наголосила на заданому наборі моделей навколо доменної моделі: вони були найбільш розумною комбінацією у 2004 році.
Однак ООП та тактична схема - це не найважливіше. Технічне оволодіння необхідне для того, щоб створити велике програмне забезпечення еволюційно. Але це лише один інгредієнт рецепту. Інші?