hckrnws

The article seems written soundly but I can't stop thinking that all these patterns discribed there are just a huge overengineering and are solving problems which don't really exist.

Thanks for the feedback. I got a bit surprised by the "overengineering" part. Especially that one of the reasons for writing this piece were the "enterprise" grade systems I've seen, which had so many layers they were hard to grasp at all.

Please note the "adaptability" feature mentioned several times in the text. Applying each of the techniques/patterns/tests should always be a conscious decision. The tutorial explicitly demonstrates, for instance, that not all modules got a separate "infra module", because their logic didn't justified it.

I try to use something between hexagonal and this, but more nested (i.e. adapters internally might use this architecture.

Sometimes Domain logic has to leak because you want to rely on certain implementation behavior: for example, logicailly there is separation of concerns, but there is a strong argument to commit these changes in a single transaction. In that case I either switch to oplog or if delay is acceptable push to my saga engine.

I'm liking what I see here. Thank you.

Thanks for the feedback!