Move hook domain logic from routes to domain

[iamacook]

Summary

With the forthcoming implementation of notification dispatch according to events, hooks will also trigger enqueuing notifications. This moves the domain-considered logic from CacheHooksService to a new HooksRepository in the domain. There the aforementioned notification-relevant logic will be placed.

Changes

• Move domain logic from CacheHooksService to HooksRepository
• Propagate changes accordingly

[coveralls]

Pull Request Test Coverage Report for Build 10004593065

Details

• 97 of 102 (95.1%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.1%) to 48.341%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/routes/cache-hooks/cache-hooks.service.ts	4	5	80.0%
src/domain/hooks/hooks.repository.ts	79	83	95.18%

Totals
Change from base Build 9991351602:	0.1%
Covered Lines:	4288
Relevant Lines:	7154

---

💛 - Coveralls

[hectorgomezv]

I think we might face a race condition here: if this onModuleInit function is executed before CacheHooksService.onModuleinit, then this.listeners would be empty, and therefore the first events wouldn't be processed by any listener, right? I don't know if they would be lost as they wouldn't be ACKed but maybe the events processing order is modified. I'd avoid relying on the class instantiation order, but maybe I'm missing something.

What do you think about moving the complete CacheHooksService implementation to the domain layer instead (including its onEvent function). To me, it was always a bit weird that this core logic lives in the routes layer so this might be a good opportunity to move it to its own class in the domain and would save us a level of indirection.

[iamacook]

Good points, with which I agree with. As of 6271732, I've moved the relevant CacheHooksService logic to the domain. Please let me know what you think.

[hectorgomezv]

🚀