问CQRS和GraphQL

EN

软件工程总是一系列的权衡。你必须放弃一些东西才能得到别的东西。不幸的是，当我们开始的时候，我们并不总是对我们的系统的影响有一个全面的了解。您在这里提到了许多原则，因此总结其背后的想法是有意义的。

不要重复你自己(干)

底线是，如果您需要改变应用程序的行为方式，您应该知道您需要去的地方，并在那里修复它。至少这是个普遍的想法。如果您曾经维护过遗留代码，您会发现各种各样的重复，这意味着您需要在多个地方修复这些东西。

干燥有用的地方是有限度的。有时你不得不重复自己的真实原因，这可能是你无法控制的，或者是由另一个解决不同问题的模式所决定的。

命令/查询责任分离(

)

这是可以被过度使用的东西，但在某些情况下是必要的。让我们来看看博客托管软件的想法。在这种情况下，读取的数量将大大超过更新(理想情况下，至少)。通过将查找和阅读博客条目的责任与创建或管理博客条目的责任分开，您可以将这些职责分开进行扩展。

一些更新非常专注也是很常见的。例如，外部系统更新状态等。命令责任不必看起来与查询响应完全相同。它确实增加了复杂性，所以确保复杂性是值得的。

GraphQL

GraphQL是一种工具，用于映射来自不同来源的数据，并将数据映射到所要求的下游系统的大小和形状中。GraphQL是它自己的语言。查询和响应大致类似于JSON，但它们不是有效的JSON对象。因此，总有一个翻译问题。

GraphQL的致命特性是，它允许您最大限度地减少通过广域网与客户端之间的闲聊，同时您可以联合到系统边界内的不同服务，在这些服务中，带宽要开放得多。

当事情不一致的时候

，

rest服务的响应对象通常不直接映射到GraphQL的模式。事实上，它们有不同的语言，所以您不能共享公共代码。此外，REST服务可以从GraphQL层用另一种语言实现。

每次在语言之间转换时，都会失去重用对象的机会。添加对新字段的支持确实需要对表示该对象的链中的每个步骤进行更改。

对于需要扩展的小型系统，您可以认为从这个过程中获得的复杂性是过分的。你可能也是对的。然而，对于流量大的大系统来说，这种复杂性不仅是必要的，而且也是必要的。

可以这样想，在异构的微服务体系结构中，服务之间没有任何共享，这样就获得了一些模块化和自由，否则就没有了。这使得必须支持新字段的团队能够在系统的其他部分准备使用该新字段之前正确地扩展和实现该字段。由于每个系统现在都开始使用它，在通过GraphQL公开之前，您有机会修复集成问题。

底线

当你进步的时候，总是重新评估你正在做的事情。

• 我的痛点是什么，我能做些什么吗？
• 对于您的应用程序，一般的方法是好的、必要的还是正确的？
• 我能做些什么来在不牺牲好的情况下减少痛苦吗？

即使你觉得自己完全走错了路，它总是有助于理解你是如何到达你现在的位置的。你所做的选择需要告诉你的新选择，特别是那些选择带来的痛苦。

有时候没有任何优雅的答案。至少现在还没有。这需要一些时间，看看你正在试图解决的问题，并播放“如果呢？”游戏开始找到驯服你创造的野兽的方法。没关系。软件开发也是团队的努力。您的团队中熟悉您的领域的人可能有一个突破性的想法来修复它。

这可能是值得实施某种类型的洞察力，以确定您的问题产生的地方。

• 应用洞察
• 普罗米修斯
• 纳古斯