У мене виникають проблеми з малюванням чіткої межі між шаром презентації та додатків у дизайні, керованому доменом.
Куди повинні йти файли контролерів, представлень, макетів, Javascript та CSS?
Це в додатку чи шарі презентації?
І якщо вони йдуть всі разом у один і той же шар, що містить інший? Це порожньо?
Відповіді:
Тільки тому, що хтось створив і назвав "Шар програми" та "Швидкість презентації", це не означає, що ваша програма повинна мати їх. Вам слід створити шари ПІСЛЯ, якщо ви створили значну кількість коду, який ви згрупували разом, і хочете назвати цю групу заради спілкування між розробниками та ясності коду.
З точки DDD. Шар програми - це все, що не є доменним шаром. До якої належать логіка програми, послуги презентації та програми.
Існує велика різниця між шаром програми та шаром презентації від точки зору DDD.
Хоча DDD зосереджується на тому, як моделювати домен за допомогою будівельних блоків та понять DDD, таких як обмежені контексти, всюдисуща мова тощо, все одно важливо чітко визначити та розділити різні шари у вашій програмі.
Архітектура відіграє велику роль у впровадженні успішного додатку DDD. Відома архітектура, яка останнім часом придбала багато галасу, - це лукова архітектура:
У цій конструкції шар інтерфейсу / презентації та шар програми чітко розділені. Об'єднання двох разом вводить тісне з'єднання між двома шарами, які мають чіткі окремі проблеми та обов'язки.
Шар презентації повинен містити лише логіку презентації. Уникайте розумних інтерфейсів, які знають занадто багато. Це, головним чином, розміщує контролери та види MVC, крім CSS, JS, шаблонів, форм і всього, що стосується об'єктів відповіді та запиту.
Дії, видані через презентацію, делегуються на рівень програми за допомогою команд. Прикладний рівень містить логіку програми. Зазвичай він відображається у випадку використання. Він містить, ЩО система повинна зробити для задоволення випадку використання. Типова служба додатків попросить сховище повернути сукупність, а потім викликати дію на цьому агрегаті.
Погляньте на зразок проекту з IDDD Вон Вернона
entry pointі composition rootрозміщуються? Я завжди думав, що це відповідальність Applicationшару. Але зараз схоже, що це Presentationшар.
Дизайн, керований доменом, не має нічого спільного ні з презентаційним шаром, ні з шаром програми. DDD - це методологія, основна увага якої зосереджена на рівні домену. Тобто DDD не накладає жодних обмежень щодо будь-якого іншого шару, окрім шару домену, і Ваше запитання також може бути задане у контексті будь-якої іншої методології.
При цьому дуже часто застосовується чотиришарова архітектура для програм DDD. Ось приклад одного такого додатка, що показує шари та їх призначення: DDDSample Architecture . Отже, якщо ви вирішите використовувати цю архітектуру, ваші погляди та макети перейдуть до рівня інтерфейсів, а контролери, якщо вони не залежать від інтерфейсу, перейдуть до рівня програми.
Ви також можете вибрати будь-який інший тип архітектури, оскільки я сказав, що DDD не обмежує обмежень. Існує багато фреймворків MVC, які мають різні структури, але вони також можуть бути використані для програм DDD. Тоді, звичайно, ви б розмістили свої погляди та макети відповідно.