Чи можете ви сказати мені свою думку про те, який шар є правильним розмістити обробники подій домену в DDD? Наприклад, у мене є служба додатків, щоб додати новий контракт, і я хотів би надіслати електронною поштою сповіщення контактній особі, коли договір буде доданий, як це відправник електронної пошти (який обробляє подію, додану до контракту), службовий додаток служби чи домен або щось ще?
Відповіді:
Я розміщую обробники подій домену в шарі додатків.
Подія домену - це спосіб повідомити зовнішнім шарам (або зовнішньому світу), що щось трапилося в доменному шарі. Що робити з подією, залежить від програми. Програма може повідомити користувача про зміни або зателефонувати іншому домену, щоб зробити щось. Програма несе відповідальність за організацію доменних операцій у відповідь на дії користувача, веб-запити або події домену.
Оригінальна книга DDD (Evans 2004) пояснює рівень програми як тонкий шар, який здійснює доменні об'єкти у відповідь на дії користувача. Типові обробники подій для подій домену, отже, не належать до рівня додатків.
Можливо, є сенс розмістити деякі з них у доменному шарі, якщо ви не порушите шари, створивши залежність вгору.
Якщо у вас є інфраструктурний рівень, розташований нижче рівня домену, обробник подій не може бути там, оскільки це порушить шари.
Якщо у вас є рівень адаптерів, що знаходиться над рівнем домену, ви можете створити там обробник подій. Перегляньте шестикутну архітектуру .
Я розміщую обробники подій домену в шарі домену як інтерфейс домену IDomainEventHandler.
Приклад обробника подій домену - це політика, яка підписується на певну подію домену з метою ініціалізації нової транзакції (наприклад, щоб запустити нову команду домену), тому має сенс мати її в рівні домену, оскільки вона пов'язана з логіка бізнесу.
Ми можемо придумати приклад, коли замовлення підтверджено, і тому слід створити запит-рахунок. У нас відбулася подія OrderConfirmedEvent, яка сталася. Політика в нашому домені буде відповідальною за підписку на цю подію та створення доменної команди, RequestInvoiceяка буде оброблятися командним обробником і відповідно до неї оброблятися.
Якби у нас був цей обробник подій у прикладному шарі, це означало б, що додаток, крім того, щоб оркеструвати дії користувача, виконував би деяку логіку бізнесу, яка видається невірною.
Однак у нас є