最近，我们在我工作的公司启动了一个项目，以重组和改写我们的系统环境并拯救我们孩子的未来。
我们有 3-4 个遗留系统，由于可怕的代码，它们绝对无法适应新的用例，但仍然每天通过不同的接口和格式（如电子邮件、xmlrpc、webinterface）处理大量订单。
所以我们考虑基于完全重新设计的领域模型从头开始编写一个新系统。由于我们不能简单地关闭旧系统并且是一个非常小的团队，我们得出的结论是，我们需要一种架构和方法，使我们能够逐步开发新系统并轻松地将其部分投入使用（阅读;快速）集成新接口、合作伙伴以及与旧应用程序和接口。
这个想法是从头开始完全重新设计整个域模型，创建一个订单服务，并使用带有 OSGi 容器的 Apache Camel 来模仿将订单路由到旧系统和新系统的旧接口，并将格式处理和传输本身解耦从新系统。由于逐步发展，我们希望选择更加“以服务为中心”的架构，这将使我们能够逐步改进，可重用性和可扩展性。这一切在纸上听起来都不错，我读了很多关于“SOA”的文章，但直到等待炒作消失和“好的部分”留下来，但大部分谈话仍然是一个非常抽象和不精确的“技术”销售”的水平。
如果我的实体有很多关系，比如订单，我发现“基本/共享数据服务”方法很成问题，而且图表很大。如果我要为 Orders 和其他实体上的 CRUD 操作创建一个单独的服务以作为更抽象的基础，那么处理 ACID、关系完整性将是非常有问题或不可能的，或者您将不得不牺牲这些服务的自主性和互连它们，这将使服务变得非常无用（并且可能非常缓慢）。还是我理解错了？
所以我的想法是使用漂亮的 JPA POJO（当然还有接口）简单地创建一个“传统”DAL，并将其部署为一个简单的、版本化的 OSGi 包，以供业务和流程服务使用，具有更抽象的映射。然后这些服务将简单地使用它并将它们的接口暴露给总线。为了满足需要访问单个数据的罕见情况，例如骆驼或批量数据导入或报告中的内容丰富，可以创建一个丑陋的“包含所有实体的服务”，这将解决 ACID 和完整性问题。
到目前为止一切都很好，但是：WebUI（正如我提到的主要是 CRUD，因此不是真正的抽象过程）应该如何访问数据？直接使用 JPA POJO 会使其耦合得非常紧密，但是创建映射并引入另一个几乎相同的模型并使用前面提到的“怪物 DAL 服务”听起来也不太好。
你怎么看？感觉、优雅和实用性之间的良好平衡在哪里？
很抱歉，这是几个问题，而且文字很长，但我觉得更详细地描述我们在这里面临的情况很重要。
感谢您的时间 ：）