Як вибрати між використанням події домену або дозволити шару додатків оркеструвати все

Я встановлюю свої перші кроки в розробці доменного дизайну, купую блакитну книгу і все, і я бачу три способи втілення певного рішення. Для запису: я не використовую CQRS або Sourcing подій.

Скажімо, запит користувача надходить у рівень обслуговування додатків. Бізнес-логіка для цього запиту (з будь-якої причини) розділена на метод на об'єкті та метод на службі домену. Як я повинен піти про використання цих методів?

Досі я зібрав такі варіанти:

• Нехай служба додатків викликає обидва способи
• Використовуйте метод введення / подвійну диспетчеризацію, щоб ввести службу домену в сутність, дозволяючи суб'єкту зробити це, а потім дозволити йому викликати метод служби домену (або навпаки, дозволяючи службі домену викликати метод на сутність)
• Підвищити подію домену методом сутності, обробник якого викликає службу домену. (Про події домену, про які я говорю, є: http://www.udidahan.com/2009/06/14/domain-events-salvation/ )

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

Нехай служба додатків викликає обидва способи

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

Використовуйте метод введення / подвійну диспетчеризацію, щоб ввести службу домену в сутність, дозволяючи суб'єкту зробити це, а потім дозволити йому викликати метод служби домену (або навпаки, дозволяючи службі домену викликати метод на сутність)

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

Підвищити подію домену методом сутності, обробник якого викликає службу домену.

Шаблон подій домену, як пояснює Уді, а також сам Еванс, досить універсальний і може застосовуватися в різних сценаріях. Однак є кілька ускладнень, які пов'язані з цим. По-перше, ви повинні переконатися, що ви належним чином встановили масштаби в межах видавця подій домену. Більшу частину часу ваші обробники подій домену матимуть залежність, і якщо ви використовуєте контейнер IoC, ви повинні переконатися, що введені належні екземпляри. Наприклад, у веб-додатку[ThreadStatic]атрибут є проблематичним для визначення обсягу. Іншою складністю є межі транскрипції. Ви повинні взяти до уваги транзакції, оскільки якщо суб'єкт господарювання піднімає подію домену, але подальша фіксація бази даних не дає змоги, всі обробники подій домену потребуватимуть способу повернення назад, інакше ви підсумите недійсну подію. Якщо ви все-таки охоплюєте ці основи, то події в домені є чудовим зразком для інкапсуляції логіки домену в самих об'єктах.

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