建立传媒公司网站,鞍山百度做网站,网站栏目规划图,建设网站文章目录 Pre如何落地 DDD底层技术的更迭 整洁架构的设计主动适配器/北向适配器被动适配器/南向适配器 整洁架构的落地总结 Pre
DDD - 软件退化原因及案例分析
DDD - 如何运用 DDD 进行软件设计
DDD - 如何运用 DDD 进行数据库设计
DDD - 服务、实体与值对象的两种设计思路… 文章目录 Pre如何落地 DDD底层技术的更迭 整洁架构的设计主动适配器/北向适配器被动适配器/南向适配器 整洁架构的落地总结 Pre
DDD - 软件退化原因及案例分析
DDD - 如何运用 DDD 进行软件设计
DDD - 如何运用 DDD 进行数据库设计
DDD - 服务、实体与值对象的两种设计思路贫血模型与充血模型
DDD - 聚合、聚合根、仓库与工厂
DDD - 微服务设计与领域驱动设计实战(上)_统一建模语言及事件风暴会议
DDD - 微服务设计与领域驱动设计实战(中)_ 解决微服务拆分难题
DDD - 微服务设计与领域驱动设计实战(下)_落地微服务设计实现
DDD - 微服务落地的技术实践 如何落地 DDD
除了在项目中实践 DDD领域建模按照 DDD 的思想设计开发以外还需要一个支持 DDD 与微服务的技术中台。在 DDD 实现过程中这个技术中台应当能够封装那些烦琐的聚合操作、仓库与工厂的设计以及相关的各种技术。有了这个技术中台的支持开发团队就可以把更多的精力放到对用户业务的理解对业务痛点的理解快速开发用户满意的功能并快速交付而不再受限于那些烦琐的技术细节从而降本增效。这样不仅编写代码减少了技术门槛降低了还使得日后的变更更加容易技术更迭也更加方便。
那么如何设计这样一个技术中台呢首先应当从现有系统的设计痛点开始分析。
底层技术的更迭
如今的架构设计需要思考如何让底层的架构更易于技术更迭、易于架构调整以应对不断演进的新技术、新框架从而获得行业竞争的技术优势。
在实际项目中特别是很多运行了七八年、十多年的老项目要做一次技术升级那叫一个费劲就像脱一层皮那么痛苦。为什么技术升级那么费劲呢究其原因是在系统设计开发时大量的业务代码依赖于底层的技术框架形成了耦合。
譬如过去采用 hibernate 进行数据持久化每个模块的 DAO 都要继承自 HibernateDaoSupport。这样所有的 DAO 都与 Hibernate 形成了一种依赖。当系统架构由 Hibernate2 升级成 Hibernate3甚至升级成 MyBatis就不是改换一个 jar 包那么简单了。
技术框架一换底层的类、接口、包名都变了就意味着上层的所有模块的 DAO 都需要改改完了还要测试。这样的技术升级成本极高风险极大需要我们认真去思考解决方案。 总之老系统技术架构升级成本极高的根源在于业务代码与底层技术框架的耦合。因此解决思路就是对它们进行解耦。如何解耦呢就是在上层业务代码与底层技术框架之间建立“接口层”。 如何在业务代码与底层框架之间建立“接口层”呢如上图所示上层业务代码在进行持久化时各个模块的 DAO 不再去调用底层框架而是对接口层的 DaoSupport 进行调用。DaoSupport 接口是我们自己设计的它应当满足上层的所有业务需求比如各种类型的 insert、 update、delete、get、load、find并让这个接口保持稳定。上层业务代码的设计实现都依赖于 DaoSupport 接口只要它稳定了上层业务代码就稳定了。
接着在 DaoSupport 接口的基础上编写实现类由实现类去调用底层技术框架实现真正的持久化。 起初使用 Hibernate2 作为底层框架所以为 Hibernate2 编写了一个实现类。 当 Hibernate2 升级成 Hibernate3 时为 Hibernate3 写一个实现类。 当底层框架要升级成MyBatis 时再为 MyBatis 写一个实现类。
这样的设计当系统进行技术架构升级时其影响就不再扩展到业务层代码而仅仅局限于调整接口层的实现类技术升级的成本将得到大幅度的降低。 整洁架构的设计 通过前面对问题的分析与接口层的设计可以得出一个非常重要的结论如何既能轻松地实现技术架构演化又能保证开发团队的快速交付呢关键的思路是将业务代码与技术框架解耦。如上图所示在系统分层时基于领域驱动的设计将业务代码都整合在业务领域层中去实现。这里的业务领域层包括了 BUS 层中的 Service以及与它们相关的业务实体与值对象。
业务领域层设计的实质就是将领域模型通过贫血模型与充血模型的设计最终落实到对代码的设计。在此基础上通过分层将业务领域层与其他各个层次的技术框架进行解耦这就是“整洁架构”的核心设计思路。 整洁架构The Clean Architecture是 Robot C. Martin 在《架构整洁之道》中提出来的架构设计思想。如上图所示它以圆环的形式把系统分成了几个不同的层次因此又称为“洋葱头架构The Onion Architecture”。
在整洁架构的中心是业务实体黄色部分与业务应用红色部分
业务实体就是那些核心业务逻辑业务应用就是面向用户的那些服务Service
它们合起来组成了业务领域层也就是通过领域模型形成的业务代码的实现。
整洁架构的最外层是各种技术框架包括 与用户 UI 的交互 客户端与服务器的网络交互 与硬件设备和数据库的交互 与其他外部系统的交互。
整洁架构的精华在于其中间的适配器层它通过适配器将核心的业务代码与外围的技术框架进行解耦。
因此如何设计适配层让业务代码与技术框架解耦让业务开发团队与技术架构团队各自独立地工作成了整洁架构落地的核心。 整洁架构设计的细化图图片来自《软件架构编年史》
如图进一步细化整洁架构将其划分为 2 个部分主动适配器与被动适配器。
主动适配器/北向适配器
主动适配器又称为“北向适配器”就是由前端用户以不同的形式发起业务请求然后交由应用层去接收请求交由领域层去处理业务。用户可以用浏览器、客户端、移动 App、微信端、物联网专用设备等各种不同形式发起请求。然而通过北向适配器最后以同样的形式调用应用层。 被动适配器/南向适配器
被动适配器又称为“南向适配器”就是在业务领域层完成各种业务处理以后以某种形式持久化存储最终的结果数据。最终的数据可以存储到关系型数据库、NoSQL 数据库、NewSQL 数据库、Redis 缓存中或者以消息队列的形式发送给其他应用系统。但不论采用什么形式业务领域层只有一套但持久化存储可以有各种不同形式。南向适配器将业务逻辑与存储技术解耦。 整洁架构的落地 按照整洁架构的思想如何落地架构设计呢如上图所示在这个架构中将适配器层通过数据接入层、数据访问层与接口层等几个部分的设计实现与业务的解耦。 首先用户可以用浏览器、客户端、移动 App、微信端、物联网专用设备等不同的前端形式多渠道地接入到系统中不同的渠道的接入形式是不同的。通过数据接入层进行解耦然后以同样的方式去调用上层业务代码就能将前端的多渠道接入与后台的业务逻辑实现了解耦。这样前端不管怎么变有多少种渠道形式后台业务只需要编写一套维护成本将大幅度降低。 接着通过数据访问层将业务逻辑与数据库解耦。 数据存储的设计可能不再仅限于关系型数据库与 3NF的思路设计而是通过 JSON、增加冗余、设计宽表等设计思路将其存储到 NoSQL 数据库中设计思想将发生巨大的转变。但无论怎么转变都只是存储形式的转变不变的是业务逻辑层中的业务实体。因此通过数据访问层的解耦今后系统向大数据转型的时候业务逻辑层不需要做任何修改只需要重新编写数据访问层的实现就可以转型成大数据技术。转型成本将大大降低转型将更加容易。 最后就是底层的技术架构。现在我们谈架构越来越多地是在谈架构演化。但是话虽如此很多系统的技术架构更迭是一个非常痛苦的过程。为什么呢究其原因是软件在设计时将太多业务代码与底层框架耦合底层框架一旦变更就会导致大量业务代码的变更各个业务模块的都要更迭导致架构调整的成本巨大、风险高昂。
既然这里的问题是耦合解决的思路就是解耦。在平台建设的过程中除了通过技术选型将各种技术整合到系统中以外还应通过封装在其上建立接口层。通过接口层的封装封装许多技术的实现以更加简便的接口开放给上层的业务开发人员。这样既可以降低业务开发的技术门槛让他们更加专注于业务提高开发速度又让业务代码与技术框架解耦。有了这种解耦就使得未来可以用更低的成本技术更迭加速技术架构演进跟上这个快速变化的时代。 总结
整洁架构的中心是基于 DDD 的业务实现即那些通过领域模型指导设计与开发的 Service、Entity 与 Value Object。整洁架构的最外层是各种硬件、设备与技术框架。而整洁架构最核心的思想是通过适配器层将业务实现与技术框架解耦这也是 DDD 落地到架构设计的最佳实践。
因此支持 DDD 与微服务的技术中台就是基于整洁架构的思想将 DDD 底层的那些烦琐的聚合操作、仓库与工厂的设计与微服务的技术框架以及整洁架构中的适配器统统封装在技术中台中。有了这个技术中台就能让上层的业务开发人员更加轻松地运用 DDD 的思想更加快捷地更迭与交付用户需求 。
