Lay Out Your Code Like You'd Lay Out Your House

This sounds really good on the face of it but something in me is suspicious that this approach won't lead to even worse confusion in a real project. Maybe I've just been working in a certain way for too long and have gotten stuck in my ways..

I'm a fan of grouping by cohesion for the reasons the author lays out, but like any principle you need to understand how and why you're applying it. The author suggests grouping reducers, actions, and components by functional cohesion in a React/Redux app, but the point of grouping by layer in this case is to uncouple the layers in your app (UI vs. store vs. actions). In this situation, those layers represent the functions around which your code coheres.

I love this concept when you are dealing with a blog that has posts and comments, or a todo app.

However..in my experiences thus far, this type of cohesion becomes increasingly complex and open to individual interpretation when you are dealing with more complex business domains. Say for example, several different types of customers engaging in several different types of transactions that have just enough differences in implementation to be several distinct models. Often there are several reasonable ways to interpret "functionality", and you end up with a situation where you are actively building what can be a fairly tricky form of technical debt over the course of years as developers come and go. From what I have experienced, the best way to avoid this, is of course more formality on the development team about structuring what goes where, but then you just end up with a different but still just as rigidly enforced structure as the first example from this article. It also has the downside of being non-standardized.

If I were going into some creature's "house", when they may very well be an alien creature whose domain and existence I understand little of, I personally feel most safe in the house that had the more "absurd" structure. I may have to walk down a few more hallways, but I won't blast myself with a ray gun looking for a faucet.

I’m all for cohesion, which it seems was the main point the author was trying to make.

But I found the first motivating example (refactoring is hard) to be a poor argument in favor of cohesion. When making a breaking public API change, types and the ensuing type errors are going to be a way more powerful guiding force for identifying affected usage sites than cohesion. Of course, his examples were in Python, so maybe the author doesn’t have such luxury.

A house where all the wire was bundled up in a single room would be weird.