领域模型中对象的层次从内到外依次是：值对象、实体、聚合和限界上下文银丰配资。
实体或值对象的简单变更，一般不会让领域模型和微服务发生大变。但聚合的重组或拆分却可以。因为聚合内业务功能内聚，能独立完成特定业务。那聚合的重组或拆分，势必引起业务模块和系统功能变化。
可以聚合为基础单元，完成领域模型和微服务架构的演进。聚合可作为整体，在不同领域模型间重组或拆分，或直接将一个聚合独立为微服务。
微服务架构的演进案例
现有 微服务 1：包含聚合 a、b、c 微服务 2：微服务 3：包含聚合 d、e、f银丰配资
当发现微服务 1 中聚合 a 的功能经常被高频访问，以致拖累了整个微服务 1 的性能，可把聚合 a，从微服务 1 中剥离，独立为微服务 2 以应对高性能场景
随业务发展，发现微服务 3 的领域模型变化，聚合 d 会更适合放到微服务 1 的领域模型。即可将聚合 d 整体迁移到微服务 1。注意定义好聚合间的代码边界
架构演进后，微服务 1 从最初包含聚合 a、b、c，演进为包含聚合 b、c、d 的新领域模型和微服务
展开剩余51%可见，好的聚合和代码模型的边界设计，可让你快速应对业务变化，轻松实现领域模型和微服务架构演进。
微服务内服务的演进
在微服务内部，实体的方法被领域服务组合和封装，领域服务又被应用服务组合和封装。在服务逐层组合和封装的过程中，你会发现这样一个有趣的现象。
在服务设计时，你并不一定能完整预测有哪些下层服务会被多少个上层服务组装，因此领域层通常只提供一些原子服务，比如领域服务 a、b、c。但随着系统功能增强和外部接入越来越多，应用服务会不断丰富。有一天你会发现领域服务 b 和 c 同时多次被多个应用服务调用了，执行顺序也基本一致。这时你可以考虑将 b 和 c 合并，再将应用服务中 b、c 的功能下沉到领域层，演进为新的领域服务（b+c）。这样既减少了服务的数量，也减轻了上层服务组合和编排的复杂度。
你看，这就是服务演进的过程，它是随着你的系统发展的，最后你会发现你的领域模型会越来越精炼，越来越能适应需求的快速变化。
发布于：湖南省红启网配资提示：文章来自网络，不代表本站观点。
相关文章
沪深京指数
热点资讯
