基于具体案例，分享选型与落地实践过程中的问题及思考。

前端项目的软件复杂度开始爆发，是时候引入 DDD 来优化前端项目了。

需求越复杂，使用DDD的收益越高。当产品只提出一个逻辑修改，而开发评估需要几十人日的时候，可能就该考虑是否应该用DDD来降低重复度，提高可维护性和效率了。

在我看来并不是MVC的基础上增加领域层，使用充血模型，解耦基础服务，我的代码就符合DDD了。

什么情况下考虑使用基于“充血”模型的 DDD 开发模式?

转转价格系统（估价器），是个十分复杂的系统，它承载着转转回收以及众多卖场的价格计算和等级计算能力，同时提供价格实验能力。由于系统的复杂性高，以下介绍的内容，是系统的一个简版。

价格系统估价的大致流程是，估价器拿到验机报告后，首先进行验机报告的解析，然后将验机报告转换为估价项。然后根据请求的参数，找到合适的报价流程，在报价流程中执行其所配置的报价方式进行价格计算。

DDD分为战略设计和战术设计，战略设计就是划分子域和限界上下文的过程。领域划分为子域的通用划分形式是把领域划分为 核心子域、支撑子域、通用子域。我们在落地过程中常常会很容易划分出核心子域，一般设计mvp的时候mvp就是核心子域。但是领域划分出核心子域、支撑子域和通用子域之后就算划分完成了吗？

在做 DDD 的培训和工作坊时，会遇到来自客户或学员的疑问，有些问题值得我们深入思考。我整理了一些常见的问题，欢迎补充和讨论。结合 DDD 社区最近的讨论成果，这里我先给出一个简单的参考答案。

了解了事件风暴的基本概念，现在把它应用于股票交易领域。我们不会一开始展示事件风暴会议产出的大量细节图，而是通过记录事件风暴产出的命令/事件对，自上而下展示待构建系统的结构。

作为DDD的入门者，向事件风暴，聚合这些概念还是比较模糊的。在IBM Developer找了一篇文章，详细介绍了DDD的基本概念和实践，翻译出来与大家分享。

商品中心随着自身业务的发展，系统复杂度逐渐变高。在业务治理过程中，我们尝试引入了DDD来辅助进行现有业务的模型重建，并在此基础上完成了中台服务能力的沉淀和对外提供。通过将核心业务逻辑下沉内聚，降低调用方的业务复杂度，防范逻辑腐化。

DDD的核心目标是通过各种实用性的方法和技巧提炼出具有体现问题实质的领域模型，解决领域问题。

众所周知Java是门面向对象的语言，但在我们传统的三层架构中却有着过程式的编码，数据模型仅当做数据的载体，几乎所有业务逻辑都是由业务逻辑层的相应方法来完成的。这样的对象只有属性(字段)没有行为(方法)是不完整的、是不符合现实世界的抽象的，比如一个人只有属性没有行为，那他就是一个植物人，是不正常的，Vaughn Vernon在《Implementing Domain-Driven Design》一书中称之为贫血领域对象。

这一篇、我们将结合 DDD 概念(国内酒店交易 DDD 应用与实践——理论篇) 和酒店交易应用场景，重点讲述用户接口层、应用层、领域层、资源层 DDD 四层架构中，酒店交易是如何落地 DDD 实施，包括实施过程中、代码层面需要注意的标准和原则。

酒店交易领域驱动设计从零到落地实践的理论背景。

本篇通过DDD代码实践来讲述软件设计的术与器，本质是为了高内聚低耦合，紧靠本质，读者可按自己的理解和团队实际情况来实践DDD即可。