适用于集成+迁移场景的重写架构

Question

最近，我们在我工作的公司启动了一个项目，重组和重写我们的系统格局，并拯救我们孩子的未来。

我们有3-4个遗留系统，由于可怕的代码，它们绝对不能适应新的用例，但仍然每天通过不同的接口和格式处理相当大量的订单，如电子邮件，xmlrpc，webinterface。

因此，我们考虑基于一个完全重新设计的领域模型从头开始编写一个新的系统。因为我们不能简单地关闭旧系统，而且我们是一个非常小的团队，我们得出的结论是，我们需要一种架构和方法，允许我们逐步开发新系统，并将其部分放在现场，轻松(读取；快速)集成新界面、合作伙伴以及与遗留应用程序和界面。

其想法是从头开始完全重新设计整个域模型，创建订单服务，并使用Apache Camel和OSGi容器来模拟将订单路由到旧系统和新系统的旧接口，并将格式处理和传输本身与新系统解耦。由于渐进式开发，我们希望选择更“以服务为中心”的架构，这将允许我们逐步改进，可重用性和可伸缩性。这一切在纸面上听起来都很好，我读过很多关于"SOA“的文章，但直到等到炒作平息，”好的部分“留下来，但大多数讨论似乎仍然停留在非常抽象和不精确的”技术销售“水平上。

我发现“基本/共享数据服务”方法很有问题，如果我有很多关系的实体，比如订单，有相当大的图。如果我为订单上的CRUD操作创建一个单独的服务，并创建其他实体作为更抽象的操作的基础，那么处理ACID、关系完整性或您将不得不牺牲这些服务的自主性并将它们互连起来将是非常有问题或不可能的，这将使这些服务变得非常无用(并且可能非常慢)。还是我理解错了什么？

因此，我的想法是简单地使用漂亮的JPA POJO创建一个“传统的”DAL，当然还有接口，并将其部署为一个简单的、版本化的OSGi包，以供业务和流程服务使用，具有更抽象的映射。然后，这些服务将简单地使用它，并将它们的接口公开给总线。为了服务于需要访问个别数据的罕见情况，比如在camel或批量数据导入或报告中进行内容丰富，可以创建一个丑陋的“所有实体包含的服务”，它将解决ACID和完整性问题。

到目前为止还不错，但是: WebUI (我前面提到的主要是CRUD，因此不是一个真正的抽象过程)应该如何访问数据？直接使用JPA POJO会使它耦合得非常紧密，但创建一个映射并引入另一个几乎相同的模型并使用前面提到的“怪物DAL服务”听起来也不太好。

你认为如何？在理性、优雅和实用性之间，哪里是一个好的平衡点？

很抱歉，这是几个问题，文本很长，但我觉得更详细地描述我们在这里面临的情况是很重要的。

感谢您的宝贵时间:)

Answer 1

与其说这是一个回答，不如说是一张祝你好运的便条。

我们有一个与你相同/不同的情况，事实证明这是一个很难有效处理的问题。

我认为你的方法是好的，听起来你找到了一个好的平衡。

您可以采用像这些published by Martin Fowler这样的企业集成模式，但这是否会将您带到您想要/需要的地方，还有待观察。

其他选择:有一个“香肠”机器:你把旧系统推到一个系统中，这个系统会生成“新”代码(用Java或.Net)，而新的代码将成为你的新平台。好消息是你现在有了一个你可以使用的语言的代码库，坏消息是它将是你想象过的最大最糟糕的意大利面。

即便如此，这也是一项艰巨的任务。这里的一个政府机构花了两三年的时间和五百万美元来完成这项工作。它并不漂亮，也不痛苦，但似乎起到了作用。如果你问得够多了(比如:不是在StackOverflow上)，你应该找到那些已经从你坚持的平台上迁移出来的人，和他们交谈。