认识达内从这里开始

java编程开发是目前大多数软件编程开发程序员都在学习和使用的一种编程开发语言，今天我们就通过案例分析来简单了解一下，DDD分层架构原则与发展趋势。

1、DDD分层架构重要的原则是什么?

架构根据耦合的紧密程度又可以分为两种：严格分层架构和松散分层架构。优化后的DDD分层架构模型就属于严格分层架构，任何层只能对位于其直接下方的层产生依赖。而传统的DDD分层架构则属于松散分层架构，它允许某层与其任意下方的层发生依赖。

那我们怎么选呢?综合我的经验，为了服务的可管理，我建议你采用严格分层架构。

在严格分层架构中，领域服务只能被应用服务调用，而应用服务只能被用户接口层调用，服务是逐层对外封装或组合的，依赖关系清晰。而在松散分层架构中，领域服务可以同时被应用层或用户接口层调用，服务的依赖关系比较复杂且难管理，甚至容易使核心业务逻辑外泄。

试想下，如果领域层中的某个服务发生了重大变更，那该如何通知所有调用方同步调整和升级呢?但在严格分层架构中，你只需要逐层通知上层服务就可以了。

2、DDD分层架构如何推动架构演进?

领域模型不是一成不变的，因为业务的变化会影响领域模型，而领域模型的变化则会影响微服务的功能和边界。那我们该如何实现领域模型和微服务的同步演进呢?

微服务架构的演进

领域模型中对象的层次从内到外依次是：值对象、实体、聚合和限界上下文。

实体或值对象的简单变更，一般不会让领域模型和微服务发生大的变化。但聚合的重组或拆分却可以。这是因为聚合内业务功能内聚，能独立完成特定的业务逻辑。那聚合的重组或拆分，势必就会引起业务模块和系统功能的变化了。

这里我们可以以聚合为基础单元，完成领域模型和微服务架构的演进。聚合可以作为一个整体，在不同的领域模型之间重组或者拆分，或者直接将一个聚合独立为微服务。

当你发现微服务1中聚合a的功能经常被高频访问，以致拖累整个微服务1的性能时，我们可以把聚合a的代码，从微服务1中剥离出来，独立为微服务2。这样微服务2就可轻松应对高性能场景。

在业务发展到一定程度以后，你会发现微服务3的领域模型有了变化，聚合d会更适合放到微服务1的领域模型中。这时你就可以将聚合d的代码整体搬迁到微服务1中。如果你在设计时已经定义好了聚合之间的代码边界，这个过程不会太复杂，也不会花太多时间。

后我们发现，在经历模型和架构演进后，微服务1已经从初包含聚合a、b、c，演进为包含聚合b、c、d的新领域模型和微服务了。

你看，好的聚合和代码模型的边界设计，可以让你快速应对业务变化，轻松实现领域模型和微服务架构的演进。你可能还会想，那怎么实现聚合代码快速重组呢?别急，后面实战篇会详细讲解，这里我们先感知下大的实现流程。

微服务内服务的演进

在微服务内部，实体的方法被领域服务组合和封装，领域服务又被应用服务组合和封装。在服务逐层组合和封装的过程中，你会发现这样一个有趣的现象。

在服务设计时，你并不一定能完整预测有哪些下层服务会被多少个上层服务组装，因此领域层通常只提供一些原子服务，比如领域服务a、b、c。但随着系统功能增强和外部接入越来越多，应用服务会不断丰富。有一天你会发现领域服务b和c同时多次被多个应用服务调用了，执行顺序也基本一致。这时你可以考虑将b和c合并，再将应用服务中b、c的功能下沉到领域层，演进为新的领域服务(b+c)。这样既减少了服务的数量，也减轻了上层服务组合和编排的复杂度。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。