Спасибо, сейчас ознакомлюсь. Хотя я прекрасно знаю, что это. Мы тоже так делаем. Только мы в отдельном файле все контракты храним, чтобы следовать правилу единой ответственности. Ну, типа ITicketSystemGateway, INotificationService.
Во многом с вами согласен. Про имейл - пример как аналогия, абстрактный. То, что вы говорите про контроллер, который вызывается в другую функцию, это 3 вариант, описанный мной. Вариант рабочий. Но когда пример более сложный, начинаешь задумываться.
Может ссылаться и ссылается, может, я неправильно вас понимаю?
да, в ваших словах есть логика. Но у такого подхода есть недостаток. Вижу, я не совсем легко и доступно объяснил, поэтому можете почитать про трилемму в ddd
Что касается событий, да, есть такое. Но мы достигаем слабой связности и других преимуществ, которые зачастую перевешивают это. В любом случае, проблема в том, что проблема не решается))
Знаете, можно по-разному. К сожалению или к счастью, теория не настолько хороша, чтобы быть универсальной и полноценной. Как всегда, все зависит от команды и проекта.
ну а доменный сервис - это все же доменный именно сервис, поскольку в нем есть бизнес-логика, которая должна оставаться на уровне домена. Если вы захотите сделать новое приложение (например, приложение для десктопа и веба у вас отличаются по тем же бизнес требованиям), то вы не размазываете эту логику по приложению, а храните все в домене для поддержания консистентности модели
Здравствуйте. В интернете сможете найти различные варианты реализации. Если необходимо, могу ссылки покидать. Как делаем мы в команде:
У нас есть BaseEntity, IAggregateRoot.
В инете в основном в одном из вариантов реализации методы событий лежат в абстракции BaseEntity. Так как мы работаем с паттерном аггрегата, то делаем еще одну абстракцию: BaseAggregateRoot, в которую и помещается маркер. И уже все наши агрегаты наследуем от нее, чтобы сами entity не могли события добавлять.
Я понимаю. Это интересно. Своего рода гибридное решение. Кстати, того же мы достигаем с интерфейсами evendhandlers в доменном слое для тех же тестов
Вы правы, различия есть. Почитал. Никогда не слышал об этом паттерне. Ценная информация. Спасибо!
Спасибо, сейчас ознакомлюсь. Хотя я прекрасно знаю, что это. Мы тоже так делаем. Только мы в отдельном файле все контракты храним, чтобы следовать правилу единой ответственности. Ну, типа ITicketSystemGateway, INotificationService.
Во многом с вами согласен. Про имейл - пример как аналогия, абстрактный. То, что вы говорите про контроллер, который вызывается в другую функцию, это 3 вариант, описанный мной. Вариант рабочий. Но когда пример более сложный, начинаешь задумываться.
Может ссылаться и ссылается, может, я неправильно вас понимаю?
да, в ваших словах есть логика. Но у такого подхода есть недостаток. Вижу, я не совсем легко и доступно объяснил, поэтому можете почитать про трилемму в ddd
Что касается событий, да, есть такое. Но мы достигаем слабой связности и других преимуществ, которые зачастую перевешивают это. В любом случае, проблема в том, что проблема не решается))
Отличное решение, по сути, тот же репозиторий, только называется по-другому
Знаете, можно по-разному. К сожалению или к счастью, теория не настолько хороша, чтобы быть универсальной и полноценной. Как всегда, все зависит от команды и проекта.
ну а доменный сервис - это все же доменный именно сервис, поскольку в нем есть бизнес-логика, которая должна оставаться на уровне домена. Если вы захотите сделать новое приложение (например, приложение для десктопа и веба у вас отличаются по тем же бизнес требованиям), то вы не размазываете эту логику по приложению, а храните все в домене для поддержания консистентности модели
Во многом с вами согласен.
Здравствуйте. В интернете сможете найти различные варианты реализации. Если необходимо, могу ссылки покидать. Как делаем мы в команде:
У нас есть BaseEntity, IAggregateRoot.
В инете в основном в одном из вариантов реализации методы событий лежат в абстракции BaseEntity. Так как мы работаем с паттерном аггрегата, то делаем еще одну абстракцию: BaseAggregateRoot, в которую и помещается маркер. И уже все наши агрегаты наследуем от нее, чтобы сами entity не могли события добавлять.