写在前面
对于领域，业务，业务模型，解决方案，BC，领域模型，微服务这些概念经常分不清，但是这些知识在进行领域建模及DDD落地过程中又比较重要。
领域，业务和业务模型
- 领域：问题域，问题空间，领域是一种边界，范围，一个领域往往代表了一个问题域的边界，业务范围越大，领域边界就越大。
- 领域围绕业务建立边界，因为业务不同，所以也存在领域的大小和领域划分，划分出来的领域成为子域，每个子域对应一个小问题或小业务，因重要性不同又划分为核心子域和支撑子域。
- 业务往往对应一个业务模型，从业务本身出发，分析业务边界范围内的各种业务场景，及业务概念之间的关系。得到业务模型最常用的方法是名词动词形容词分析法，还有比如四色原型分析，找到一个适合自己的，业务模型提炼了业务核心概念及其关系，可以帮助我们更好理解业务本身。
解决方案
进行DDD实践时，回进行需求分析，领域划分，领域建模等工作，系统落地则需要一套解决方案，如果实现一个电商平台，需要一个复杂的系统解决方案，如果方案设计的过大，各模块，组件柔和在一起，就不利于整个系统维护-演进-伸缩等需求。所以需要对解决方案进行拆分，成为一个个独立的小的解决方案。
领域代表问题域，解决方案代表解空间
解决方案的拆分往往没有捷径，还是需要经验，对系统的熟悉程度等情况。利用软件设计的各种原则，最佳实践，设计模式，非功能特性需求，及团队情况来指导我们解决方案的拆分和落地。
拆分有时可以从性能角度切入，有时可以从业务角度切入，有时可以借助CQRS，或者伸缩性角度考虑，找到适合自己团队和项目本身情况，最合适的就是最好的。
BC
BC作为界限上下文，是DDD的核心概念，有Bounded和Context两个概念，一个场景纠缠多种上下文，是一个时空感的概念。 通过上下文边界可以对边界内的领域模型进行对象概念的明确，如果没有这个上下文边界，同一个概念可能存在歧义，理解上产生偏差。比如商品在商品中心的BC中是聚合根，而在订单的BC中含义不同，只是一个值对象。
领域模型
领域模型是DDD中的核心概念，是业务拆分，软件设计的综合结果，任何一个领域模型，都是在特定的BC边界内才有意义。
业务模型是对业务概念及其关系的表达，领域模型在业务模型基础上，采用OOA/D的思想进行进一步抽象的设计模型，领域模型中有聚合，实体，值对象的区分。多个业务模型可以杂糅到某个领域模型之中。
进行领域建模大致的过程：
- 得到业务模型
- 运用软件设计思想和原则对业务模型进行模型提炼
微服务
微服务出现之后，对于微服务的划分和DDD中BC有很大的契合点，有相同的探寻边界的原则。
总结
- 领域=问题域=问题空间=业务边界
- 每个业务的问题都可以推导出一个业务模型
- 领域拆分，业务建模，是需求分析阶段需要做的事情
- 解决方案的拆分，领域建模，是软件设计阶段该做的事情
- 解决方案的边界就是BC
- BC边界契合微服务的边界
转载于:https://my.oschina.net/u/1000241/blog/3059215