维护系统不同端的数据契约的最佳做法

Question

我目前正在研究我们系统中组件之间的数据契约的最佳实践。现在，当合同变更时，我们坚持使用Word文档和JIRA票据。数据变化非常频繁(添加新特性、取消推荐和删除旧特性等等)并且必须建立几个新的合同来处理更新的速度。这开始变得混乱，甚至在我们的开发系统中导致灾难性的失败。

我们目前正在使用Java (后端，生成所有数据)和灵丹妙药(中间件)与我们的前端通信。幸运的是，由于maven的工作方式，我们对更改几乎没有任何问题。对于我们的中间件来说，情况并非如此。

• 与系统不同目的订立合同的最佳做法是什么？
• 是否有任何好的工具/资源来帮助维护和建立合同？可能是Git工具？JIRA插件(我们讨厌汇合，也使用它)

Answer 1

从所描述的情况来看，整个系统似乎没有明确的边界，很可能，也不是很好的设计。如果可能的话，退一步，反思，重新划定边界(我想不止一个团队正在开发这个系统，因此每个团队的代表都需要在场，如果是单独的，也需要操作)。

总的思想是在组件之间建立极简的API。您可能已经很好地理解了更改最频繁发生的地方，因此您可以大致了解组件的相对稳定性。这里的良好实践是使不稳定组件依赖于稳定的组件和反向依赖关系，以及所有这些良好的设计模式。

有问题的/遗留的/快速变化的系统可能需要包装在领域驱动的设计(DDD)所谓的反腐败层。把它加到引起大部分疼痛的地方。实际上，DDD的元素可以帮助您准确地解决问题，即使您没有完全遵循它的哲学。您可以从理解有界的上下文及其集成的不同方式开始，参见https://www.culttt.com/2014/11/26/strategies-integrating-bounded-contexts/。其主要思想是使系统不那么复杂，更好地符合业务需求。DDD的战术模式是次要问题。

另一种有用的方法是保持API(您的数据契约)版本化，并保持组件版本兼容性的图表。(类似于任何包装系统，比如Debian的)。这需要一些纪律，例如，作为每个组件发布的定义的一部分。我知道，Java和Elixir都有很好的系统来处理依赖的包。工具？由你决定。就我个人而言，我发现语义web引擎: RDF/OWL和推理引擎能够满足这一任务，具有声明性，易于设置和维护，尽管需要学习一些图形数据库原理和查询语言。当然，需要保持阶段/生产状态以推断结果的兼容性，所以最好连接到某种连续传递系统(很难说出您现在的CD规模在哪里，但自动化是关键)。

另外，打包/发布信息最好在部署编排/编排系统理解的表单中有一个“主数据”，而不是MS word。当然，可以找到跨平台工具(也许，会有工具推荐的答案)。而存储系统版本图也可以在git中实现。也许，您需要使用发行版而不是git版本来简化维护。

至于中间件，依我所理解的热交换代码，Elixir允许您的中间件甚至不必停止进行切换。与版本控制相结合，这意味着在许多情况下可以同时使用多个版本(您的中间件没有绑定到严格的数据库模式，对吗？)

如果您设计了一些声明性的方法来描述这些数据契约，那么ala可以作为编写文档、测试，甚至自动生成适配器代码的基础，您可能希望在组件的边界上这样做。

这个答案并不是装作过于具体或包罗万象。试着打破常规思维:你是你的系统中最好的专家。