在软件设计中，“越小越好”几乎普遍是坏建议，例如针对数据库分区，消息大小，μsvcs，有界上下文，类名，方法一致性等。一些关键业务逻辑会越过这些细粒度边界，并导致实施不当。
小粒度事物看起来很简单，因为错误不是隐藏在事物内部，而是隐藏在它们的连接中。
事物边界会变大，很少变小或稳定。@CarloPescio在软件物理学中称此为重力（具有质量的事物获得更多质量），我们通常的反应是提倡小重力。
然后“使其变小”被误解为“尽可能使其变小”。提出一种简单的规则比容易犯错的竞争性网络平衡启发法要舒适得多。
“Just right”是一个答案，但是如果没有定义它的工具，这是一个毫无意义的短语。
抽象是另一个情况，如果用不好，就变得有害，“不良抽象不好”变成了“抽象本身不好”。
banq：
莱布尼兹的Monads是一种不可分割的最小实体，带有自己的微事务，是一种没有零件的简单物质。
https://www.jdon.com/53600