微服务和强制模块化

您的代码中的模块化是什么？

听说过单一职责原则吗？它本质上是相同的，但我们不是将其应用于单个类，而是将其应用于一组相互关联的代码——有界上下文（借用领域驱动设计的一个术语）。

与类类似，作为模块，您希望代码如下：

• 低耦合——注意创建依赖项的数量和类型
• 高度内聚 - 你希望模块中的代码紧密相关

许多编程语言默认都具有逻辑上将代码分组的机制。
例如，在 C# 中，我们有命名空间。在 Java 中，我们有包。

您隔离这部分代码并赋予它一个代表其目的的名称，要非常小心地确定它所依赖的内容，因为任何外部依赖都可能将您的模块与其他东西耦合在一起。

如果外部模块需要通信，那么您可以定义一个公共接口来满足该需求！

你为什么要这么做？

因为它从逻辑上将你的系统分解成更小、更独立的块，而不是像意大利面条一样被弄成一个大球！如果你的所有代码都可以在任何地方被引用，而不管业务环境如何，那么代码的可读性就会变得极其困难。

单一代码库的困难

您可以（并且应该！）在任何应用程序中创建模块化软件 - 但如果您只有单一代码库，这可能会很有挑战性，因为对于放置代码的位置没有实际的物理限制。

由于您可以简单地引用代码的其他部分并将它们引入，因此有人可以轻易地破坏模块的设计原则。

像这样：

另外，别忘了数据库！在单个代码库中，通常也只有一个数据库——这意味着即使你的代码可以完全分离，你的查询现在也可以跨模块创建依赖关系，因为你可以跨不同的上下文进行连接！

微服务是如何进来的？

微服务通过创建物理限制来帮助解决这种情况，因为代码和数据库被分成更小的、独立的部分。

你可以把一个模块（或几个！）变成一个微服务，这样就不容易从系统其他地方添加不属于它的代码了。虽然仍然有可能，但不像连接表或导入新的命名空间那么简单！

不仅如此，由于每个微服务都必须有自己的数据库，因此您也无法跨不同的域进行查询。