nie*_*sch 5 java architecture soa dependency-management maven
我们有一个类似 soa 的架构，看起来像这样
\n\nfrontend ->domain A ->db \nfrontend->business A->domain B ->db\nfrontend ->domain C ->db\nfrontend ->domain A ->db \nfrontend->business B->domain B ->db\nfrontend ->domain C ->db\n\nother app A\nother app B\n我们还有其他不属于此 soa 堆栈的应用程序。
\n\n我们不时会遇到以下讨论/问题：
\n\n“我在域 A 中的代码在域 B 中也有用，但在业务服务中不起作用 - 我应该将这些内容及其测试放在哪里”。
\n\n让我们假设代码非常抽象且与领域无关，是非常通用的代码，也可以被 soa 之外的“其他”应用程序使用。
\n\n所以问题是：
\n\na) 将其放入“generic-domain-stuff”模块中，所有域都通过 Maven 依赖项继承该模块。这可能最终会越来越大，直到变成一团糟\xe2\x80\xa6。
\n\nb) 创建一个模块“generic-stuff”，可供 soa 和“其他”应用程序使用。这可能会导致很多小的maven模块\xe2\x80\xa6。
\n\nc) 复制代码直到拥有三个用例，然后重构为 a) 或 b)。这尖叫干（不要重复自己）
\n\n我周围有超过 10 年“企业”经验的人，但我们似乎从来没有找到一个适当的解决方案/答案来解决总是相同的问题:)
\n\n我有兴趣听听你的经历
\n(b) 应该是正确的出路。如果代码/逻辑如此通用，那么它最适合库。需要此逻辑的应用程序应通过 maven（或任何其他依赖项管理机制）使用该库。你不应该让一个图书馆成为“神图书馆”。随着时间的推移，将图书馆分成更小的有凝聚力的部分。这样你就可以防止它变得太大而变得一团糟。不用担心许多 Maven 库 - 许多小型且内聚的库比一个大型整体“全能”库更好。