安徽省两学一做网站专栏,做平面设计买哪个素材网站会员,公司网站开发用什么软件,莆田做网站排名文章目录 Pre概述打造快速交付团队烟囱式的开发团队(BAD)大前端技术中台(GOOD) 技术中台的特征简单易用的技术中台建设总结 Pre
DDD - 软件退化原因及案例分析
DDD - 如何运用 DDD 进行软件设计
DDD - 如何运用 DDD 进行数据库设计
DDD - 服务、实体与值对象的两种设计思路… 文章目录 Pre概述打造快速交付团队烟囱式的开发团队(BAD)大前端技术中台(GOOD) 技术中台的特征简单易用的技术中台建设总结 Pre
DDD - 软件退化原因及案例分析
DDD - 如何运用 DDD 进行软件设计
DDD - 如何运用 DDD 进行数据库设计
DDD - 服务、实体与值对象的两种设计思路贫血模型与充血模型
DDD - 聚合、聚合根、仓库与工厂
DDD - 微服务设计与领域驱动设计实战(上)_统一建模语言及事件风暴会议
DDD - 微服务设计与领域驱动设计实战(中)_ 解决微服务拆分难题
DDD - 微服务设计与领域驱动设计实战(下)_落地微服务设计实现
DDD - 微服务落地的技术实践
DDD - 整洁架构_解决技术设计困局 概述
以往建设的系统都分为前台和后台前台就是与用户交互的 UI 界面后台就是服务端完成的业务逻辑操作。然而在我们以往开发的很多业务系统中有一些内容是共用的部分在未来开发的业务系统中也要使用。
因此如果能把这些内容提取出来做成公用组件那么在未来开发系统就简单了不用每次都重头开发复用这些组件就可以了。
但是这些公用的组件到底属于前台还是后台呢都不属于。它既包含前台的界面也包含后台的逻辑因此被称为“中台”。所谓的中台就是将以往业务系统中可以复用的前台与后台代码剥离个性、提取共性形成的公用组件。有了这些组件就可以使日后的系统开发降本增效、提高交付速度。因此阿里提出了“小前台、大中台”的战略得到了业界的普遍认可。
从分类上看中台分为业务中台、技术中台与数据中台。 业务中台就是将抽象的业务组件如用户权限、会员管理、仓储管理、物流管理等公用组件做成微服务各个业务系统都可以使用。 技术中台就是封装各个业务系统所要采用的技术框架设计出统一的 API使上层的业务开发技术门槛降低、开发工作量减少、提升交付速度。 数据中台则是整理各个业务系统的数据建立数据存储与运算的平台为各个系统的数据的分析与利用提供支持。
DDD 与微服务的技术中台的设计思路。它是将 DDD 与微服务的底层技术进行封装从而支持开发团队在未来实现快速交付以应对激烈竞争的市场。因此首先必须要清楚实现快速交付的技术痛点才能清楚这个技术中台该如何建设。 打造快速交付团队
许多团队都有这样一个经历项目初期由于业务简单参与的人少往往可以获得一个较快的交付速度但随着项目的不断推进业务变得越来越复杂参与的人越来越多交付速度就变得越来越慢使得团队越来越不能适应市场的快速变化从而处于竞争的劣势。然而软件规模化发展是所有软件发展的必然趋势。因此解决规模化团队与软件快速交付的矛盾就成了我们不得不面对的难题。
烟囱式的开发团队(BAD) 为什么团队越大交付速度越慢呢如上图是我们从需求到交付的整个过程。在这个过程中我们要经历多个部门的交互才能完成最终的交付大量的时间被耗费在部门间的沟通协调中。这样的团队被称为“烟囱式的开发团队”。
烟囱式的开发团队又会导致烟囱式的软件开发。如上图所示在大多数软件项目中每个功能都要设计自己的页面、Controller、Service 以及 DAO需要编写大量的代码并且很多都是重复代码。代码写得越多 Bug 就越多日后变更也越困难。 最后统一的发布也制约了交付的速度。如上图当业务负责人将需求分配给多个团队开发时A 团队的工作可能只需要 1 周就能完成。但是当 A 团队完成了他们的工作以后能立即交付给客户吗答案是不能因为 B 团队需要开发 2 周A 团队只能等 B 团队开发完成以后才能统一发布。统一的发布制约了系统的交付速度即使 A 团队的开发速度再快不能立即交付用户就不能产生用户价值。
随着系统规模越来越大功能越来越多、越来越复杂开发系统的团队规模也越来越大。这样就会导致开发团队的工作效率越来越低交付周期越来越长技术转型也越来越困难。 大前端技术中台(GOOD) 特性团队的组织形式
如何解决这一问题呢 首先需要调整团队的组织架构将筒状的架构竖过来称为“特性团队”。 在特性团队中每个团队都直接面对终端客户。比如购物团队面对的是购物功能所有与购物相关的功能都是他们来负责完成包括从需求到研发从 UI 到应用再到数据库。最后经过测试也是这个团队负责上线部署。这样整个交付过程都是这个团队负责没有了那么多团队间的沟通协调交付速度自然就提升了。 有了特性团队的组织形式如果还是统一发布那么交付速度依然提升不了。因此在特性团队的基础上软件架构采用了微服务的架构即每个特性团队各自维护各自的微服务。这样当该团队完成了一次开发则自己独立打包、独立发布不再需要等待其他团队。这样交付速度就可以得到大幅度提升。如下图所示 特性团队 微服务架构可以有效地提高规模化团队的交付速度。
然而仔细思考一下就会惊奇地发现要这样组建一个特性团队成本是非常高昂的。团队每个成员都必须既要懂业务也要懂开发既要懂 UI、应用还要懂数据库甚至大数据做全栈工程师。如果每个特性团队都是这样组建每个成员都是全栈工程师成本过高是没有办法真正落地的。那么这个问题该怎么解决呢
解决问题的关键在于底层的架构团队。这里的架构团队就不再是架构师一个人而是一个团队。 架构团队通过技术选型构建技术中台将软件开发中诸如 UI、应用、数据库甚至大数据等诸多技术进行了封装 然后以 API 接口的形式开放给上层业务。
这样的组织形式业务开发的技术门槛将得到降低开发工作量也会减少。这样特性团队的主要职责将发生变化即从软件技术中解脱出来将更多的精力放到对需求的理解、对业务的实现从而提高用户的体验这就是“大前端”。所谓大前端是一种职能的转变即业务开发人员不再关注技术而是更加关注业务深刻地理解业务并快速应对市场对业务需求的变化。
采用“大前端技术中台”的战略为了团队设计能力以及交付速度的提升需要架构团队的支撑。架构团队从业务开发的角度进行提炼提炼共性、保留个性将这些共性沉淀到技术中台中。这样的技术中台需要 DDD 与微服务架构的支持。通过将 DDD 与微服务涉及的各个技术组件封装到技术中台中封装各个技术细节就能很好地支持各业务团队快速开发业务快速交付用户进而让团队获得市场竞争优势。 技术中台的特征
通过以上的分析我们理清了技术中台建设的需求。为了提高开发团队的交付速度提升市场竞争力需要在系统的底层进行技术中台的建设。打造这样一个支持快速交付的技术中台应当具备以下特征。 (1) 简单易用、快速便捷的技术中台 它能够明显降低软件开发的工作量使软件系统易于变更、易于维护、易于技术更迭进而明显降低业务开发人员的技术门槛。 (2) 易于技术架构演化 我们打造的技术中台可以帮助开发团队调整技术架构进行技术架构演化并有效地降低技术架构演化的成本。这就要求系统在进行架构设计时能够有效地将技术框架与业务代码解耦。采用整洁架构、六边形架构、CQRS 等架构设计模式就可以帮助我们完成解耦。 (3) 支持领域驱动与微服务的技术架构 领域驱动设计的思想但要将这样的思想落地到软件项目中甚至最终落地到微服务架构中也需要这样一个技术中台支持领域驱动与微服务技术架构。 简单易用的技术中台建设
首先我们来看一看如何打造一个简单易用的技术中台即如何简化开发。以往的软件项目在研发的过程中需要编写太多的代码这既加重了软件研发的工作量延缓了软件交付的速度又使得日后的维护与变更成分加大。软件研发的一个非常重要的规律就是 你写的代码越多可能出现 Bug 的概率就越高日后的维护与变更就越困难 你写的代码越少Bug 就越少日后维护与变更就越容易。
因此我们设计软件应当秉承这样的态度宁愿花更多的时间去分析设计让软件设计精简到极致从而花更少的时间去编码。
接着看一看在以往软件研发过程中存在的问题。以往的软件项目在研发的过程中需要编写太多的代码了每个功能都要编写自己的 UI、Controller、Service 和 DAO。并且在每一个层次中都有不同格式的数据因此我们编写的大量代码都是在进行各个层次之间的数据格式转换。如下图所示 譬如前端以 Form 的形式传输到后台这时后台由 MVC 层从 Model 或者 Request 中获得然后将其转换成值对象接着去调用 Service。然而从 Model 或者 Request 中获得数据以后由于我们在 MVC 层的 Controller 中写了太多的判断与操作再将其塞入值对象中所以这里耗费了太多的代码。
接着在 Service 中经过各种业务操作最后要存盘的时候又要将 VO 转换为 PO将数据持久化存储到数据库中。这时又要为每一个功能编写一个 DAO。我们写的代码越多日后维护与变更就越困难。那么能不能将这些转换统一成公用代码下沉到技术中台中呢基于这样的思想系统架构调整为这样 在这个架构中将各个层次的数据都统一成值对象这是怎样统一的呢首先在前端的数据现在越来越多的前端框架都是以 JSON 的形式传递的。JSON 的数据格式实际上是一种名 - 值对。 可以制订一个开发规范要求前端 JSON 对象的设计与后台值对象的格式一一对应。这样当 JSON 对象传递到后台后MVC 层就只需要一个通用的程序以统一的形式将 JSON 对象转换为值对象。这样还需要为每个功能编写 Controller 吗不用了整个系统只需要一个 Controller并将其下沉到技术中台中。
同样Service 在经过了一系列的业务操作最后要存盘的时候可以这样做制作一个vObj.xml 的配置文件来建立对应关系将每个值对象都对应数据库中的一个表哪个属性就对应哪个字段。这样DAO 拿到哪个值对象就知道该对象中的数据应当保存到数据库的哪张表中。这时还需要为每个功能编写一个 DAO 吗不用了整个系统只需要一个 DAO。 总结
通过以上的设计思想架构的系统开发工作量将极大地降低。
在业务开发时每个功能都不用再编写 MVC 层了就不会将业务代码写到 Controller 中而是规范地将业务代码编写到 Service或值对象中。接着整个系统只有一个 DAO每个功能的 Service 注入的都是这一个 DAO。
这样真正需要业务开发人员编写的仅限于前端 UI、Service 和值对象。而 Service 和值对象都是源于领域模型的映射因此业务开发人员就会将更多的精力用于功能设计与前端 UI 提高了交付速度。
采用 DDD 是为了更深刻地理解业务做出用户满意的产品还需要快速交付产品以应对竞争激烈且瞬息万变的市场。这两方面需要双管齐下才能获得市场竞争的优势。因此我们不仅要学习 DDD还要学习如何建立支持 DDD 的技术中台实现快速交付。
点击 GitHub 链接查看源码。
