三、模块编码
传统的三层结构是web,service,dao，这个大伙都很熟悉，一个业务流程稍微复杂点会导致service里面的代码变成大泥球，我在上一份工作中，见过一个service类达到上万行，维护及其痛苦，怎么痛苦法呢，就是每次转测试，都会产生20多个bug，改完又会出现新的，一轮一轮无法收敛。我实在受不了，就跟项目经理申请重构，项目经理是不同意的，没办法只能立军令状，就开干了，最终一万多行代码变成4000行左右，bug终于收敛。
解决service层大泥球的一个方法是分离复杂性，把service分为应用层和领域层，这块内容可以参考王林在infoq的文章
（https://www.infoq.cn/article/A3cgSUWuRulXHl2c_dUr），文章中提到了一个架构原则是业务和技术分离。领域层放业务逻辑，应用层放技术逻辑，复杂性降低，并且领域层更便于测试。
DDD战术设计就是把业务逻辑放到最核心位置，整洁架构和六边形架构也是如此，跟业务相关的代码写到实体，值对象和领域服务里面，一些事务，缓存等技术相关代码写到应用服务里面。
举例说明：购物车有个操作是添加商品到购物车，应用层
ShoppingCartApplicationService把事务，缓存处理掉，核心业务逻辑在ShoppingCart这个领域对象里面。
领域层代码如下：
应用层代码如下：
四、总结
DDD的统一语言在软件开发过程中能帮助业务知识更好的传递，限界上下文能指导复杂系统的拆分，战术设计能帮助代码更好的分层。
有的公司虽然没有用DDD这么一套组合拳，可能已经在利用这些好的方法来开发软件，其实DDD提供一套方法论，也不是必须全部用上，完全可以只借鉴其中一部分。比如DDD的统一语言是通过降低业务知识的传递提升效率，可以应用到实际开发中。
举一个实际的例子，很多企业内部系统也采用了前后端分离，然后用前端开发和后台开发两拨人分别开发，再接口联调，联调成本很大，完全可以换一种方式，让后台开发来做前端，节省联调成本。
那这里可能有人有疑问，后台开发做前端会不会效率很低？其实只要让前端提供了架子和前端组件，再辅助一些组件使用文档和代码示例，后台开发完全可以很快上手，而节省的联调成本会很可观。
最后想说一句，方法论能提供指导，但也不要生搬硬套，需要根据自身情况进行裁剪，灵活运用。
