Investigate package cycles in lending about library HOT 3 CLOSED

Problematic dependencies include: events, PatronId, book types

from library.

Answering your question @dosdebug regarding the cycles, it is true that conceptually a patron can hold (among others) a book, and a book can be held by a patron. What event storming sessions has uncovered, though, is that it is the patron that we're interacting with directly in order to place a book on hold, collect it, etc. It means that there is a relation: patron -> book which is unidirectional. In other words, a patron depends on a book, and this dependency should be reflected in the code as well.

Considering it further, having bidirectional dependencies, including PatronEvents, PatronId, BookType, we introduce coupling, loosing orthogonal package structure, components' autonomy, etc.

Does this sound reasonable?

I already started analysis with ArchUnit test (actually, I could put in into some branch to share with you - will do it soon) which shows all cycle-related issues. There are a couple of ways of solving them, and we need to align it with our model to keep arch-code gap minimized.

As soon as I push the branch with mentioned test, we can continue with it.

from library.

@bslota Sure. I got it, so we need to maintain uni-directional communication.

from library.