3 ms·
I believe a simpler explanation is that it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separat
by mixedCase 9y ago
I believe a simpler explanation is that it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separation, rather than language modules/packages, where it's too easy for a junior dev to break the architecture with a single import.
Keeping a monolith's concerns cleanly segregated does require a small amount of discipline.
- XorNot 9y agoI would propose that an alternate explanation is that when the processes are actually separate in deployment, you filter out strong personalities (or management types who are overly involved in things outside their area) from dominating the development process as well. Stopping someone working in one area from deciding they just don't like the look of the other is a benefit or all its own.
- crdoconnor 9y ago>it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separation This is a dangerous ideology. Process separation doesn't enforce loose coupling, it simply makes the pain of tight coupling between them that much worse. I worked on a "microservice" system once where I regularly had to debug a problem across four different service boundaries and two different languages. It felt like I was using boxing gloves to perform surgery on a rube goldberg toy.
- phamilton 9y agoConway's law explains why that discipline is harder in practice. If everything about the business suggests that two things are tightly coupled, then naturally someone is going to make that import.