3 ms·

The problem arises when you need to read the code of other modules or services. If you can rely on them working as they should, and interact with them using the

The problem arises when you need to read the code of other modules or services. If you can rely on them working as they should, and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code. I'm a proponent of keeping things in a monolith as long as possible. Break code into files. Organize files into modules. A time may come when you need to separate out services. Often, people break things out too early, and don't spend enough effort on thinking how to break things up or on the interfaces.

rightbyte 4y ago
> The problem arises when you need to read the code of other modules or services. If you can rely on them working as they should, and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code. You can say the exact same thing about C-headers though.
pshirshov 4y ago
> and interact with them using their well-defined and correctly-behaving interfaces, you won't need to read the code. Don't you want determinism and deterministic simultations? If you do, you'll also need stub implementations (mocks, dummies) for your interfaces. Some notes on that: https://blog.7mind.io/constructive-test-taxonomy.html https://blog.7mind.io/constructive-test-taxonomy.html > A time may come when you need to separate out services. Most likely it won't if you organise properly. For example, if each your component is an OSGi module.