在解释完了各种概念以及举例子之后，我们对DDD是什么有了个大概的认知，相信也是有非常多的争议。作者搞微服务已经搞了多年，也曾经在梳理业务的时候被DDD的各种黑话毒打过，也使用过DDD搞过工程。经历了这么多这方面的实践之后觉得DDD最大的价值其实还是在梳理业务的时候划分清楚业务领域的边界，其核心思想其实还是高内聚低耦合而已。至于工程方面，现在微服务的粒度已经足够细，完全没必要再多这么一层。这多出来的这一层，多少有种没事找事的感觉。更可笑的是，这个概念本身在对外普及自己的东西的时候，玩足了文字游戏，让大家学的一头雾水。真正好的东西，是能够解决问题，并且能够很容易的让人学明白，而不是一昧的造新词去迷惑人，也希望以后互联网行业多一些实干，少说一些黑话
| 分层 | 描述 |
|---|---|
| 控制层 | 对外暴漏的接口层，举个例子，java工程的controller |
| 逻辑层 | 主要的业务逻辑层 |
| 领域能力层 | 模型层，系统的核心，负责表达业务概念，业务状态信息以及业务规则。即包含了该领域（问题域）所有复杂的业务知识抽象和规则定义。 |
| 数据层 | 操作数据，java中主要是dao层 |
这个是对于DDD在战术设计阶段的运用，以java项目来举例子，现在的搞微服务的，都是把工程分为了主要的三层，即控制层->逻辑层->数据层，但是到了DDD这里，则是多了一层，变成了控制层->逻辑层->领域能力层->数据层。这里一层一层来解释下：
基础设施层即为我们要做的东西，为业务应用层提供通用的用户权限能力、以及售卖的能力，同时构建开发者中心、租户控制台以及运营后台三个基础设施应用。
最后再根据实体和实体之间的交互，划分出了用户中心服务以及计费服务，这两个服务是两个通用能力服务，然后又划分出了基于通用服务的业务层，分别是租户管理端和运营后台以及提供给业务接入的应用中心，架构图如下：
根据上面的业务流程，我们梳理出了下图中的实体
4、基础设施还需要对其他业务系统赋能。
3、权限系统需要能够根据租户购买的功能以及用户拥有的角色来鉴权，如果是私有化，由于客户此时购买的是完整系统，所以此时权限系统仅仅根据用户角色来鉴权即可。
2、高级的功能，比如客服中的机器人功能是属于要花钱买的，试用期不具备此权限，用户必须出钱购买。每次购买之后会生成购买订单，订单对应的商品即为高级功能包。
1、用户可以自行注册租户，也可以由运营在后台为用户开通租户，每个租户内默认有一个超级管理员，租户开通之后默认有系统一个月的试用期，试用期超级管理员即可在管理端进行用户管理，添加子用户，分配一些基本权限，同时子用户可以使用系统的一些基本功能。
在经过比较细致的梳理（DDD管这个叫事件风暴/头脑风暴）之后，我们整理出了主要的业务事件，大致如下：
这是对于DDD在战略阶段做的事情：假如目前我司有个客服系统，内部的客服人员使用这个系统对外上亿的用户提供了形形色色的服务，同时内部人员觉得我们的客服系统也非常好用，老板觉得我们的系统做的非常好，可以拿出去对外售卖以提高公司的利润，那么这时候问题就来了，客服系统需要怎样去改造，才能够支持对外售卖呢？经过激烈的讨论，大致需求如下：