主要是面向平台研发团队而非应用开发者设计，提供很多强大灵活的能力。但是，这不仅带来了陡峭的学习曲线，影响了应用开发者的使用体验，甚至在很多情况下理解不当还会引发错误操作，乃至生产故障。
比如上下文，领域，子领域这三个词。所以对于划分出来的划分方案可能就是一份文档，一个对于应用架构落地的指导性方案。那么这时候，领域可能是一个部门负责的，可能是一个平台系统，可能是一个单独的微服务，也可能是更细致上的模块。
那么这时候，领域可能是一个部门负责的，可能是一个平台系统，可能是一个单独的微服务，也可能是更细致上的模块。
最终，当你觉得概念很难理解的时候不妨先放一下，去真正体验一下
领域驱动设计中的统一语言在现实情况下的应用场景。
领域划分的依据
现在我们先直观的回答这个问题，我这边从以下个方面来阐述一下领域划分的
依据，可能不够全面，如果有其他依据欢迎交流讨论。
重点在于营销和优惠是不是在业务流程中存在多次，如果说业务刚起来有优惠
的场景。那么此时就去识别优惠领域，构建一个营销优惠平台可能就不太合适
。
相信大家稍加思考就会明白，times函数只有解析完命令行参数才能调用，这就要求命令行参数要事先定义好，如果把参数定义放到 times，这就意味着只有调用 times函数时才会解析相关参数，这就跟让手机根据外壳颜色变换主题一样无理取闹，可是，真的是这样吗？
才能定义 echo times 这个子命令。实际上，在很多场景下，父命令是没有执行逻辑的，特别是以 resource 作为父命令的场景，父命令的唯一作用就是打印这个命令的用法。
各层数据对象
VO（View Object，视图对象）：该层的视图数据对象主要的作用就是将应用层的数据进行组装后形成用于页面展示的视图数据。
我们会关心这个桌子是哪里生成的，编码是什么以及规格是怎样的吗？显然不会，有空位坐就可以了。当然我们还是需要关注值对象上下文的，如刚才的例子，我们消费者并不关心坐哪个位子，但是商家是关心的，因为他要根据桌号来进行上菜以及收账。
到这里我们实现 DDD 落地的所有准备工作都差不多了，后面的文章中我们将根据真实的业务场景进行真正的落地实践，从业务分析到领域建模，从领域分层到代码实现。我想通过这一系列的理论加实践的方式，相信大家可以真正领悟到 DDD 的魅力所在。
