有一个域的目的是在众多公司之间进行协调。该过程通过请求和通知消息进行通信，每个消息都通过Web服务（SOAP）请求进行传输。每个公司都必须提供自己的SOAP端点才能接收请求消息，并且必须以Web服务客户端的角色发送通知。
手头的规范描述了该过程，并且有描述接口的XSD和WSDL文件。
设计参与实现的首选方法是查看域，找出无处不在的语言（基于规范）并创建域模型。我想尽可能地将域作为基础设施/技术的不可知实现，请阅读：在针对Java EE，JPA时，我希望将基础架构依赖/库保留在核心域代码之外。
当我应用这种方法时，我可以实现一个非常好的规范语言的域模型。在目前这一点上，我甚至确信它在规格中相当模糊的细节上真的很有表现力。然而，域模型与XSD描述的Web服务模型有很大不同。
请注意：该系统的未来用户和运营商（假设为领域专家并分散在所有参与公司中）很可能会针对请求和消息进行辩论在SOAP接口上。因此，这两个模型之间将不断需要进行转换，例如当我的系统用户与开发人员交谈时，有人直接查看数据库时，...
第二种可行方法可能是强制在Web服务，域模型和持久性之间进行硬性对齐。可以使用HyperJAXB3将从XSD生成的类映射到持久层。由于我在适当的手工制作模型中使用了@Embedded，并且我简化并统一了一些模型元素，因此产生的数据库表的数量差异很大，大约是因子5.这使得基于XSD的数据库模式更加困难把握。
所以我的“简单”问题是：我是否应该努力在 此 域中实现webservice，域模型和持久性之间的一致性，因为沟通是最重要的我应该继续使用手工制作更具表现力的领域模型的（首选）解决方案吗？
欢迎参考。
答案 0 :(得分：1)
在使用或不使用DDD的决策过程中评估最相关的一点是域模型复杂性。
如果它“足够”复杂且需要在整个时间内保持，那么DDD可以是一个选项。
在我看来，您的域模型与已经由现有框架建模的概念（请求，通知，消息，ecc。）的相似性并不相关：它们只为您提供了简单快速地构建解决方案的可能性，如果您决定不使用DDD。
我建议你也阅读this