通过代码共享避免耦合

Question

我一直在开发一个应用程序，该应用程序由几个衔接服务( Customer、Invoice、PurchaseOrder、Highlight )组成，应用程序部署在单个回购系统中，每个服务都按功能安排打包在自己的目录中。

应用程序是无服务器的，每个实体(除了突出显示)都由一个dynamo DB表支持，最初是o.k的，系统是松散耦合的，函数被部署为AWS lambda函数。

很快，需求就意味着，例如，Invoice服务需要来自PurchaseOrder服务的数据，所以最简单的方法是在Invoice的lambda部署中包含PurchaseOrder的助手，然后查询dynamo。

我现在几乎已经完成了这个应用程序并回顾了过去，而我一开始就怀着良好的意愿，即高内聚力和松散耦合，一旦交付压力增大，我就开始跨包“代码共享”，现在整个应用程序都得到了紧密的耦合。

突出显示包实际上只是显示在仪表板上的大量键值，例如未付款发票的数量、未支付发票的百分比低于一定百分比的订单数量等，因此跨越所有逻辑服务，因此这是最紧密耦合的包。

我正在寻找一些建议，我可以如何对抗这种紧密的耦合，以便我可以避免在未来再次。一种方法是调用API的跨包来获取我所需的数据，例如，Invoice函数可以通过PurchaseOrder包中的API网关端点调用，但这会增加额外的延迟，也会带来额外的成本。

Answer 1

在现代软件开发中，您遇到了一个正在进行的仔细平衡的问题。越松散地耦合组件，就越不可能同时依赖于多个组件的性能优化。

例如，如果您想提取一个链接所有Customer、Invoice和PurchaseOrder数据的报表；最有效的方法是编写一个查询并让数据库服务器优化其查询。这是db服务器倾向于专门研究的内容。

但是，从编码的角度来看，这会立即混淆松散耦合的组件，因为您定义的三个域实体之间没有明显的分离。

从代码结构的角度来看，您更希望分别获取Customer、Invoice和PurchaseOrder数据，这样就可以使这些组件相互独立。这对您的代码结构非常好，但是您的查询性能将因此而受到影响。

这里我使用存储库作为示例，但同样适用于您的情况。您被困在松散耦合的服务和通过耦合服务来优化事物之间。

无论您重视性能还是代码结构，我们都无法普遍回答。

当我一开始就怀着良好的意愿，即高内聚力和松散耦合，在交付压力增大的时候，我就开始了跨包的“代码共享”，现在已经在整个应用程序中得到了紧密的耦合。

在我的母语中有一句谚语，意思是“最后的石头似乎最重”。

这就是经典的发展故事。这甚至不是具体的发展，同样也适用于大多数人们倾向于承担的项目，例如建造房子，打扫房子，或者画一些东西。

一开始，他们以干净的笔触开始，保持效率和优雅。但是在项目结束的时候，当事情结束的时候，遇到了一些小小的阻碍，人们更有可能把事情扫到地毯下，然后用它们来完成。没有人想重新做基础，当他们已经做了最后的细节工作。

旁白:我住的房子就是这种行为的纪念碑。这不是我造成的，以前的所有者也是这样做的(我只是租了它)，但作为一个软件开发人员，它让我很开心，而且让我很恼火。

这是人的本性，我们之所以这么做是有道理的--尽管你冒着后悔自己的决定的风险。特别是在软件开发中，代码库的超乎寻常的长寿命特性最终会让您回心转意，这就是为什么优秀实践开发人员对不良实践如此敏感的原因。

这里的主要优点是，当你第一次打好基础的时候，你不能现实地期望你会预先正确地计划好所有的事情。相反，当需要进行调整时，您需要将期望转移到调整基础上。这有很多种形式。

当需要调整的时候，干净的编码实践有助于减轻负担。

但是，有时后期的更改需要对代码库进行重大更改，这需要一个PO或团队领导，他对干净代码的重视程度足以将所需的精力和时间投入到代码中。通常情况下，即使使用最干净的编码实践，后者也是导致这类问题的原因，而作为开发人员，您通常没有覆盖此问题的权限。充其量，你可以希望改变你的PO/团队领导/经理的想法，给你必要的时间。