У меня небольшая головная боль с моей библиотекой фрагментов. По сути, это упрощает мне написание кода, который не связан с какой-либо структурой (что позволяет мне быстро переносить его с одной платформы (скажем, Nest) на другую (скажем, LoopBack))
Он использует много sh Принципы доменного дизайна для достижения этого. Но в конце вы открываете службу приложения, а также некоторые интерфейсы для служб, которые необходимо определить в инфраструктуре (фреймворке) и передать в службу приложения (т.е. репозитории и доменные службы).
Например, если у меня был класс MongoUserRepository, который я определил в своей структуре, который мне нужно передать в UserApplicationService, я делаю это при инициализации, например:
const userServive = new UserApplicationService(new MongoUserRepository());
Теперь моя библиотека имеет эту функцию что позволяет вам регистрировать методы в качестве слушателей событий. Так, например, в совокупном классе я могу зарегистрировать слушателя для события UserRegistered, украсив метод следующим образом:
@On(UserRegistered)
private async foo(event: DomainEvent): Promise<void>{}
Это делает его так, когда генерируется событие UserRegistered
await EventStream.publish(new UserRegistered(user));
будет выполнен прослушиватель foo (event).
Итак, вот в чем проблема. Слушатели событий - это методы уровня класса. То есть доступа к «этому» нет. Итак, я не могу получить доступ к переданным зависимостям службы приложения (первый фрагмент кода). То есть в моем классе UserApplicationService я не смог бы сделать это:
@On(UserLoginAttemptsExceeded)
private static async lockUser(event: DomainEvent): Promise<void>{
const theEvent = event as UserLoginAttemptsExceeded;
const id = theEvent.user().id();
const user = await this.userRepo.findById(id):
user.lock();
await this.userRepo.save(user);
}
, потому что прослушиватель событий не имеет доступа к this, когда он вызывается диспетчером (когда EventStream. publi sh (SomeEvent) вызывается).
Как я разработал библиотеку, вы можете регистрировать слушателей из любой точки домена. Это может быть служба приложения, агрегат, объект или доменная служба. Или как там. Таким образом, простое изменение декоратора для использования контекста «this» не сработает.
Моя текущая работа прямо сейчас состоит в том, чтобы сделать все мои репозитории одноэлементными и просто передать делегат, который определен в инфраструктуре (framework ). Но это не совсем так элегантно, как хотелось бы.
Работает. Но это не так элегантно, как хотелось бы. К тому же это не фиктивное доказательство. Кто-то, не знакомый с шаблонами проектирования, вероятно, просто обойдется с этим ...
Есть какие-нибудь советы, как я могу улучшить дизайн этого?