这一阶段是需求评审，主要目的是和领域专家一起划好子域，界限上下文，明确领域术语。

领域

领域指的是一个有明确边界的业务范围。对于大部分项目而言，领域的划分是明确的，以电商为例，那大体有订单，商品，仓储这些领域。领域的划分没有对错之分，大家达成一致即可。领域又分为核心域，通用域，支撑域，其含义就是字面意思。子域类型对写代码并没有什么影响，只是影响人力资源的分配，核心域要投入更多的人，功能上更完备，仅此而已。

限界上下文

有时在同一领域下，同一术语有着不同的含义，为了区分这一点，引入了限界上下文的概念。以英雄联盟为例，虽然都是说“盖伦”，但是在峡谷上下文和商城上下文里，我们的关注点是完全不一样的。一个关注的是技能，血量等，一个关注的是价格，皮肤等。在代码落地时，限界上下文应作为最顶层文件夹，而不是领域，领域不必在代码里体现。不过大部分情况下，领域和限界上下文是重叠的，不必刻意去区分。

因为有了限界上下文做隔离，所以文件和文件夹的名称不用那么长，只表达本身的含义即可；在不同的限界上下文中，允许有同名的文件夹或文件夹。

领域术语

指的是领域所包含的实体，用例等的名称，比如电商的订单，商品等。大家都用同一套名字，沟通起来比较舒畅。

术语的名字要最终体现在代码上，实体的类名就应该是实体的术语名称，用例函数的名称就是用例名称。如果大家定的是中文，那么就应该是中文。这样是为了确保代码是领域专家/产品可以浏览和审阅的(指的是应用层和领域层代码，因为其他层是业务无关的)。关于中文命名这一点，可以看下我的这个回答。

要保持领域术语的一致性，这个一致体现在一是开发人员和领域专家，产品，测试保持一致，二是前后端试保持一致。

以我们的todo应用为例，很显然这个一共两个领域：鉴权域和待办域。
鉴权域主要处理注册登录，权限校验相关的业务；待办域处理待办相关的业务。
待办域作为核心域；鉴权域作为通用域。
鉴权域下的术语是“角色”，“用户”，“当前用户”；待办域下的术语是“待办”。

在条件有限的情况下，至少应该保证应用层的函数/模块命名和用例图保持一致，因为它不仅是程序员的维护入口，也是产品和领域专家的浏览入口。