我们有一个看起来像这样的soa-ish架构
frontend ->domain A ->db
frontend->business A->domain B ->db
frontend ->domain C ->db
frontend ->domain A ->db
frontend->business B->domain B ->db
frontend ->domain C ->db
other app A
other app B
我们还有其他应用程序不属于这个soa堆栈。
我们不时会有以下讨论/问题：
“我在域A中的代码在域B中也很有用，但在商业服务中却没有 - 我应该把这些东西放在哪里进行测试”。
让我们假设代码是非常抽象的和域不可知的，非常通用的东西也可以被soa之外的“其他”应用程序使用。
所以问题是：
a）将它放在“generic-domain-stuff”模块中，所有域都通过maven依赖继承。这可能会最终成长并增长，直到它变得一团糟......
b）创建一个模块“generic-stuff”，可以由soa和“其他”应用程序使用。这可能会导致许多小型maven模块......
c）复制代码，直到你有三个用例，然后重构为a）或b）。这是DRY（不要重复）
我的人有10年以上的“企业”经验，但我们似乎从来没有找到适当的解决方案/答案总是同样的问题：）
我很想听听你的经历
答案 0 :(得分：2)
（b）应该是要走的路。如果代码/逻辑是如此通用，那么它最适合库。需要此逻辑的应用程序应通过maven（或任何其他依赖关系管理机制）使用库。你不应该允许一个图书馆成为“神图书馆”。随着时间的推移，将图书馆分成更小的连贯片段。这样你就可以防止它变得太大而变得一团糟。不要担心许多maven库 - 许多小而有凝聚力的库比一个大的单片“do it all”库更好。