微服务和ddd领域设计模型

微服务解决的是服务的治理问题的。对于服务的拆分没有很明确的指导意义的。使用领域驱动设计模式ddd可以很方便的指导微服务的拆分问题的。从而补充和完善微服务拆分的问题的。两者之间对应的是一个互补的关系的。
我们都知道，架构一个系统的时候，应该从以下几方面考虑：
功能维度
质量维度（包括性能和可用性）
工程维度
springcloud 更加关注的是服务的扩展性以及其他的质量属性的。对于功能维度的拆分以及工程维度是没有很明确的管理措施的。

从架构角度看，微服务中的服务所关注的范围，正是 DDD 所推崇的六边形架构中的领域层，和整洁架构中的 entity 和 use cases 层。
#系统架构的含义:系统架构的目标是需要做到架构拆分，确定架构之间的依赖关系的。通俗一点的说法是如下的：系统架构需要解决解耦问题的，系统架构在拆分的时候存在一个问题：如何进行架构拆分才能保证满足要求了？讲一个整体的架构拆分成为多个组件并且体现出来各个组件的边界以及组件之间的依赖关系的。
系统架构是由系统内部的架构边界，以及边界之间的依赖关系所定义的，与系统中组件之间的调用方式无关。
所谓的服务本身只是一种比函数调用方式成本稍高的，分割应用程序行为的一种形式，与系统架构无关。
*架构的目标可以这么理解:如何将一个整体的事物拆分成为多个部分，明确出来多个部分的职能以及确定彼此职能的依赖关系，从而形成整体上的协同效果来完成一个完整的事物的。
ddd的思想：解决一个复杂的问题，我们可以这