This is good stuff and makes me rethink about one of my personal projects.
However, I have reserved opinion about the idea that a module should only access its direct children. More than often, I find modules interact with each other forming a loop, either by direct function calls or by message passing. If having to organize all modules into tree structure, I sometimes find it is hard to decide which modules should act as parents without introducing additional layers of abstraction. Also, what if I would like to pass a message from children to their parent? As according to the article, it is better to make children swappable and do not rely on parents' code, either direct calling parental functions or passing message to parent's pid looks bad, all I can think of is to use an event bus, which is extra complexity. Not to mention after so many abstractions module names could be too long to be clear.
Personally now I am good with parent, children, and siblings talking to each other, beyond these is probably too far. Not every module needs to be swappable, and too much abstraction makes stuff harder to understand and not always easier to maintain. Erlang thrived probably even before TDD was there with its "let it crash" philosophy. I do not mind not having 100% test coverage, as long as every crash scenario has been fixed along the way and possibly test guarded.
However, I have reserved opinion about the idea that a module should only access its direct children. More than often, I find modules interact with each other forming a loop, either by direct function calls or by message passing. If having to organize all modules into tree structure, I sometimes find it is hard to decide which modules should act as parents without introducing additional layers of abstraction. Also, what if I would like to pass a message from children to their parent? As according to the article, it is better to make children swappable and do not rely on parents' code, either direct calling parental functions or passing message to parent's pid looks bad, all I can think of is to use an event bus, which is extra complexity. Not to mention after so many abstractions module names could be too long to be clear.
Personally now I am good with parent, children, and siblings talking to each other, beyond these is probably too far. Not every module needs to be swappable, and too much abstraction makes stuff harder to understand and not always easier to maintain. Erlang thrived probably even before TDD was there with its "let it crash" philosophy. I do not mind not having 100% test coverage, as long as every crash scenario has been fixed along the way and possibly test guarded.