From: https://liudongdong1.github.io/
微服务架构，在集中式架构中，系统分析、设计和开发往往是独立进行的，而且各个阶段负责人可能不一样，那么就涉及到交流信息丢失的问题， 另外项目从分析到开发经历的流程很长，很容易最终开发设计与需求实现的不一样，微服务主要就是解决第二阶段的这些痛点，实现应用之间的解耦，解决单体应用扩展性的问题。
面对客户的业务需求，由<code>领域专家与开发团队</code>展开充分的交流，经过<code>需求分析与知识提炼</code>，以获得清晰的问题域。通过<code>对问题域进行分析和建模</code>，<code>识别限界上下文</code>，<code>利用它划分相对独立的领域</code>，再通过上下文映射<code>建立它们之间的关系</code>，辅以<code>分层架构与六边形架构划分系统的逻辑边界与物理边界</code>，<code>界定领域与技术之间的界限</code>。之后，进入战术设计阶段，深入到限界上下文内对领域进行建模，并以领域模型指导程序设计与编码实现。若在实现过程中，发现领域模型存在重复、错位或缺失时，再进而对已有模型进行重构，甚至重新划分限界上下文。 两个不同阶段的设计目标是保持一致的，它们是一个连贯的过程，彼此之间又相互指导与规范，并最终保证一个有效的领域模型和一个富有表达力的实现同时演进。
在<code>一个大的问题空间中会同时存在很多的小问题域</code>，而这些<code>小问题域往往只有少部分是核心领域</code>，其他的可能都是通用域和支撑域。核心域是我们软件的根本竞争力所在，因此也可以说是我们编写软件的原因。拿一个在线拍卖网站来说，可以见下图所示划分了核心域、支撑域和通用域：
<code>模型驱动设计专注于实现以及对于初始模型可能需要修改的约束</code>，<code>领域驱动设计则专注于语言、协作和领域知识</code>，他们是一个彼此互补的关系。而要实现协作，就需要使用通用语言，借助通用语言可以将分析模型和代码模型绑定在一起，并最终实现团队建模。实践UL是一个持续的过程，多个迭代后会不断对UL进行验证和改进，以便实现更好的协作。 由于时间和精力都有限，只有仅仅为核心域应用模型驱动设计和创建UL才能带来最大的价值，而不需要将这些实践应用到整个应用程序之中。
领域模型模式：适用于复杂问题域，领域中的概念被封装为数据和行为的对象
事务脚本模式：组织所有的领域逻辑来满足业务事务或用例
表模块模式：代表着以对象形式建模的数据，数据驱动
活动记录模式：类似表模块，数据驱动，关注表中的行而非表本身
贫血模式：类似领域模型，不包含任何行为，纯粹的一个对象状态模型，需要一个单独的服务类来实现行为
从<code>展现层</code>、<code>领域逻辑层</code>再到<code>持久化层</code>的完整代码堆栈，正应对了我们的每一个<code>微服务的应用程序</code>，也具有较高的独立性，拥有自己的数据库和一套完成的垂直切片的架构模式。<code>不应该局限在某一种或者两种架构模式上，而是应该量身应用</code>，没有复杂性业务逻辑的微服务，那就应该KISS（Keep It Simple & Stupid），否则就可以考虑DDD。
上下文映射用来<code>捕获各个有界上下文之间的技术与组织关系</code>，它最大的作用就是<code>保持模型的完整性</code>。在战略设计阶段，针对问题域，通过引入限界上下文和上下文映射可以对问题域进行合理的分解，识别出核心领域和子领域，并确定领域的边界以及他们之间的关系，从而维持模型的完整性。 限界上下文不仅局限于对领域模型的控制，而在于<code>分离关注点之后，使得整个上下文可以成为独立部署的设计单元</code>，这就是我们非常熟悉的“微服务”的概念；而上下文映射的诸多模式则对应了微服务之间的协作。
http://www.uml.org.cn/sjms/202105104.asp?artid=23938