当我们要落地DDD的时候就会遇到一个问题DDD的很多东西都放在哪里，怎么跟框架进行结合，网上也很少有案例。技术组件知道都放在基础设施层里，但是其他代码元素比如dto,实体，值对象，仓库这些应该怎么放.怎么去匹配dubbo等技术框架，怎么跟其他层的代码元素进行交互完成业务逻辑。
这里其实借鉴了COLA架构和DDD分层架构来画的一张图。比较明显的是领域层是可以单独拿出来的.这也与之前的讲述是一致的.DDD建模就是要表达业务需求的核心内容，当作核来看待。因此这个领域层的Jar会被应用层和基础设施层分别引用。
前面几小节已经讲述了DDD的理论模式和业务架构风格，这里我们就进入实战环节，看看如何使用DDD来构建一个博客帖子平台。
这里使用四色建模法来构建模型图。限于篇幅我大概讲一下建模过程，先确定业务关键时刻，如上图的博客/帖子/微博等。然后针对这个对象产生了一些其他相关的业务活动，我们对这些相关的业务互动继续建模，为其添加角色和描述则得到了上图的建模内容。
我们用四色建模法得到的模型图来继续构建UML类图，在这个类图中我们对相关的业务对象抽象了一些业务行为，如上图。
这里借助cola分包的策略来构建博客帖子平台的整体工程包内容，另外这也相当于用了DDD的战术模式--模块模式
这里我们看一下发布博客帖子的时候涉及到哪些领域，以及这些领域的上下文关系，我们从这些领域的交互中能提炼哪些事件消息。
这里我们看一下发布博客的整体流程，假设这是有多个业务服务构成的业务流程，先由博客领域发起业务活动，
然后由下游的审批服务和运营服务辅助博客领域完成发布博客的业务操作。
在博客核心服务的内部，我们看一下运用CQRS模式来编写发布博客的整体业务调用流程。这里将博客核心服务分为四层进行建设，有区别的地方就在于读的地方是不一定要先走领域层再到基础设施层的，在松散分层架构下这种情况也是允许的。经过上面的实战之后，这里我也简单列一些关于DDD的最佳实践。如果要用DDD解决问题的话，我们需要做哪些内容呢，首先是团队整体需要认可DDD的思想有意愿用DDD。一个人玩DDD容易达到瓶颈。后续就可以按照DDD的一些模式来构建文档和代码，如此循环。
下面我们看一些DDD落地的策略，防止落地过程中出现各种各样的问题。对于第二，三，四点我要表达的意思就是说团队中不要因为这些架构，框架和规范的因素影响我们使用DDD。对DDD的理解不同的人有不同的看法有时候会有偏见，在进行DDD建模落地到代码的时候，就很容易导致问题。
