Simplifying Application Architecture with Modular Design and MIM

[codingfox]

https://codingfox.net.pl/posts/mim/

I’ve written a deep dive into Software Design focusing on the "gray area" between High-Level Design (system architecture) and Low-Level Design (classes/functions).

What's inside:

* A step-by-step tutorial refactoring a legacy big-ball-of-mud into self-contained modules.

* A bit of a challenge to Clean/Hexagonal Architectures with a pattern I've seen in the wild (which I named MIM in the text).

* A solid appendix on the fundamentals of Modular Design.

(Warning: It’s a long read. I’ve seen shorter ebooks on Leanpub).

[0x457]

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.

[mono442]

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.

[codingfox → mono442]

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.

[scrubs]

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

[codingfox → scrubs]

Thanks for the feedback!