To understand how SAIDs work
Little confused... this is telling me about how "SAIDs" work... I thought I already learned that... the #1 below seems very CESR related... are SAIDs and CESR tightly coupled? or are they independent concepts? Making an ID with an eye toward how it will be serialized seems... unnecessarily coupled.
I emphatically disagree with BlueFish about observers being difficult to properly unit test. This is precisely the biggest point that distinguishes them from lifecycle callbacks: you can test observers in isolation, and doing so discourages you from falling into many of the state- and order-heavy design pitfalls BlueFish refers to (which again I think is more often true of lifecycle callbacks).
Rails' observers were partly inspired by aspect-oriented programming -- they're about cross-cutting concerns. If you're putting business logic in observers that is tightly coupled to the models they're observing, you're doing it wrong IMO.
Maybe the source code was originally thought to be independent but was later discovered to be “rightly coupled”.
Very often in these monorepos, packages are so incredibly specific in functionality, the question then becomes why even have a separate package at all if it’s tightly coupled? Can you use these packages independently or are they tied to specific versions of other packages in the monorepo? It’ll probably be easier to remove the mask and just work as a monolith.