这种方法是内网中的一篇文章，我觉得很有实践意义，就利用自己的理解重新梳理一下。
当我们拿到一个需求，从小需求到项目再到新系统的搭建，应该都是有一套方法论可以指导落地。如果按照DDD的方式来落地架构的话，一般系统可以分成三层，从内到外分别是领域模型层、领域服务层、应用服务层，可以对外接口还会有一层，例如微服务接口，web接口等。那么我们需要做的就是将需求转换成上面的层级结构。
需求分解
需求分解的目的是得到用例(User Case)，在互联网企业中技术得到的往往是一个PRD，是对一个需求的流程描述，属于一个比较粗粒度的描叙，只是一个主干流程，没有细化到一个个用例，也么有对于异常情况进行描叙。
边界划分
边界划分是按照一定规则与约束将User Case涉及的功能划分到不同的域，可以是不同的系统，也可以是同一个系统中的不同的域中。
一个没有任何规则约束的随意设计会产生一些无法理解的整体含义且很难维护的系统。
边界划分可以利用单一职责作规则为主要的约束，但是职责并不是一个太好量化的东西，在之前如何编写类中思考了一些方法。另外《UML和应用模式》中的GRASP也可以用来辅助划分，引用内网一篇文章的图片
用例拆解
当已经划分好边界，那就可以对每个用例进行分解，分解成每个小的步骤，然后对每个步骤进行聚类分组，形成如下的层级结构：Commond -> Phase -> Step。
模型的沉淀
用例拆解将每个用户拆解成了一个数据执行的pipeline，但是系统中的模型业务语义表达能力不强，因此需要不断的梳理出系统中重复的地方，然后进行能力的下沉，找到这些逻辑真正的归属。
总结
利用上面几步基本可以完成需求到架构的落地，尤其是用例的拆解与模型的沉底，实践起来比较容易。
