Я читаю Еванс дизайн, керований доменом, і я зараз обговорюю шарувату архітектуру. Я щойно зрозумів, що шари додатків і доменів різні і повинні бути окремими. У проекті, над яким я працюю, вони наче поєднуються, і я не можу сказати різниці, поки не прочитаю книгу (і не можу сказати, що це мені зараз дуже зрозуміло), насправді.
Мої запитання, оскільки обидва вони стосуються логіки програми та мають бути чистими з технічних та презентаційних аспектів, які переваги нанесення межі цих двох?
Відповіді:
Нещодавно я сам читав DDD. Коли я потрапив до цього розділу, я був приємно здивований, дізнавшись, що виявив ту саму 4-шарову архітектуру, що і Еванс. Як вказував @lonelybug, доменний шар повинен бути повністю ізольований від решти системи. Однак щось має перевести значення, що стосуються інтерфейсу користувача (рядки запитів, дані POST, сеанс тощо) у об’єкти домену. Тут грає прикладний шар. Його завдання полягає в перекладі назад і назад між користувальницьким інтерфейсом, рівнем даних і доменом, ефективно приховуючи домен від решти системи.
Я бачу дуже багато додатків ASP.NET MVC зараз, де майже вся логіка в контролерах. Це невдала спроба втілити класичну 3-шарову архітектуру. Контролерам складно перевірити тестування, оскільки вони мають стільки проблем, що стосуються інтерфейсу. Насправді, написання контролера таким чином, щоб він не стосувався безпосередньо значень "Http Context", є серйозною проблемою саме по собі. В ідеалі контролер повинен просто виконувати переклад, координувати роботу і виплютати відповідь.
Це навіть може мати сенс робити основну перевірку на рівні додатків. Добре, щоб домен прийняв значення, що входять до нього, має сенс (чи це дійсний ідентифікатор для цього клієнта і чи ця рядок представляє дату / час). Однак перевірка, що включає ділову логіку (чи можу я забронювати квиток на літак раніше), повинна бути зарезервована для доменного рівня.
Мартін Фаулер насправді коментує, наскільки рівними є більшість шарів домену в наші дні . Незважаючи на те, що більшість людей навіть не знає, що таке прикладний шар, він виявляє, що багато людей складають досить тупі доменні об'єкти та складні шари додатків, які координують роботу різних об’єктів домену. Я в цьому сам винен. Важливо не створити шар, тому що вам сказали деякі книги. Ідея полягає в тому, щоб визначити відповідальність і відокремити наш код на основі цих обов'язків. У моєму випадку, "рівень додатку" розвивався природним чином, коли я збільшував тестування одиниць.
Беручи з моделей Мартіна Фаулера дизайн підприємства, найпоширенішими шарами є:
Презентація - це перегляди, шаблони презентацій, які генерують інтерфейс взаємодії для вашої програми (я використовую взаємодію, якщо доступ до вашої програми іншими системами через веб-сервіси або RMI, тому може не бути користувальницьким інтерфейсом). Сюди також входять контролери, які вирішують, як виконувати дії та як.
Домен - тут розміщені правила та логіка вашого бізнесу, визначені моделі вашого домену тощо
Джерело даних - це шар відображення даних (ORM) та джерело даних (база даних, файлова система тощо)
Як намалювати межі між трьома шарами:
Не ставте певну логіку презентації у ваших моделях чи об’єктах домену
Не вкладайте логіку на свої сторінки та контролери, тобто логіку для збереження об'єктів у базі даних, створення підключень до бази даних тощо, що зробить ваш рівень презентації крихким і складним для перевірки
Використовуйте ORM, який дозволяє від'єднати доступ до джерела даних та дії від моделі
Дотримуйтесь тонкої контролер - парадигма жирної моделі, контролери - це контроль процесу виконання, не виконуючи його, докладніше на http://www.littlehart.net/atthekeyboard/2007/04/27/fat-models-skinny-controllers/ та http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model модель, перегляд та контролер,
У доменній шар моделює бізнес - додатки. Це має бути ваше чітке тлумачення правил, це динаміка компонентів і містить стан у будь-який момент.
Шар додатки є «стурбовані» визначення робочих місць , необхідних належить зробити для виконання певного завдання програми. Головним чином, він відповідає за доручення необхідної роботи над доменом та взаємодіє з іншими (зовнішніми чи ні) службами.
До прикладу , моє додаток фінансового програмного забезпечення операція користувача для зміни стану модельного об'єкта (об'єкт , як це визначено в DDD [89]):
Але, як процес подання заявки, окрім усіх модельних наслідків цієї операції, я маю надсилати внутрішнє повідомлення іншим користувачам програми. Цей вид роботи "оркестрований" у додатковому шарі. Я б не хотів, щоб мій доменний шар думав про спрямування служби обміну повідомленнями. (і, звичайно, це не відповідальність презентаційного шару). Як би там не було, одне напевне: мені потрібен новий шар, оскільки мій доменний шар - це все про основний бізнес, а мій рівень презентації - це інтерпретація команд користувача та представлення результатів.
Примітки:
Доменний шар повинен бути розроблений як ізоляційний рівень, що означає, що бізнес-логіка та правила не повинні впливати на будь-які зміни кодів (у шарі додатків, презентаційному шарі та інфраструктурному шарі).
Припускається, що рівень додатків повинен бути розроблений для надання деяких функцій щодо того, що може робити інтерфейс системи (програми) (думаю, такий як API чи RESTful). Наприклад, користувачі можуть увійти в систему, і в цій дії програми (логін) коди рівня додатків будуть кодами клієнта для шару домену (або інфраструктурного шару), в якому витягується об’єкт домену Користувача і застосовуються методи цього об'єкта для реалізації функція "входу".
Шар програми також повинен бути розроблений як ізоляційний шар, що означає, що на поведінку програми не повинно впливати жодні зміни коду (у шарі презентації, шарі домену та інфраструктурному шарі).
Сенс моделювання, керованого доменом, полягає у відокремленні основної моделі домену та її існуванні без будь-яких залежностей від інших шарів та інших проблем із застосуванням.
Це дозволяє зосередитись на самому домені без відволікань (наприклад, координація між інтерфейсом користувача та службами збереження).
Основна причина цих меж - розділення проблем . Код, який має доступ до сховища даних, повинен турбуватися лише про доступ до сховища даних. Він не повинен нести відповідальність за примусове застосування правил над даними. Крім того, користувальницький інтерфейс повинен відповідати за оновлення елементів управління в інтерфейсі, отримання значень від введення користувача та переведення їх на те, що може використовувати доменний рівень, і більше нічого. Слід викликати операції, надані доменним шаром, для виконання будь-яких необхідних дій (наприклад, збереження цього файлу). Викликана веб-служба повинна відповідати за перетворення середовища передачі в те, що може використовувати доменний рівень, а потім викликає доменний рівень (більшість інструментів робить для вас багато цієї роботи).
Таке розмежування при правильному впровадженні може надати вам можливість змінювати частини коду, не зачіпаючи інших. Наприклад, можливо, потрібно змінити порядок сортування повернутої колекції об'єктів. Оскільки ви знаєте, що шар, відповідальний за маніпулювання даними (зазвичай шар бізнес-логіки), обробляє цей матеріал, ви можете легко визначити, де код потрібно змінити. Крім того, що не потрібно змінювати спосіб отримання даних із сховища даних або будь-якого з додатків, що використовують домен (інтерфейс користувача та веб-служба з мого прикладу вище).
Кінцева мета - зробити свій код максимально простим у обслуговуванні.
Як бічна примітка, деякі речі не можуть бути зафіксовані в конкретному шарі домену (наприклад, реєстрація, перевірка та авторизація). Ці елементи зазвичай називають наскрізними проблемами, і в деяких випадках їх можна розглядати як шар, який стоїть сам по собі, що всі інші шари можуть бачити та використовувати.
Особисто я вважаю, що шаруватий підхід застарів, і що сервісний підхід є кращим. У вас все ще є чітка лінія в піску, хто робить що, але це не змушує вас бути настільки ієрархічними. Наприклад, послуга замовлення на купівлю, послуга виставлення рахунків та послуга доставки, з точки зору програми всі ці служби представляють ваш домен, і відкладене вище відповідальність я досі діє в цьому контексті, вона щойно була змінена що ваш домен існує в декількох місцях, додатково використовуючи концепцію розділення проблем.
