网站开发入门培训机构,wordpress中文相册插件下载,外贸网站 开源,g2g有哪些网站前言#xff1a; 谈到“架构”这两个字#xff0c;会有好多的名词闪现#xff0c;比如:分层架构、事件驱动架构、DDD、CQRS等。亦或者一堆的软件设计原则#xff0c;如#xff1a;KISS原则#xff08;Keep it Simple and Stupid#xff09;、SOLID原则(单一责任原则、开…前言 谈到“架构”这两个字会有好多的名词闪现比如:分层架构、事件驱动架构、DDD、CQRS等。亦或者一堆的软件设计原则如KISS原则Keep it Simple and Stupid、SOLID原则(单一责任原则、开放封闭原则、里氏替换原则、接口分离原则、依赖导致原则)等。甚至如状态图、用例图、时序图、活动图等UML建模GOF设计模式等。 本文不会讨论这些架构概念而是从闲鱼详情页这个业务场景出发分析出当前的业务问题和痛点然后通过一步步的架构推导设计解决这些痛点。随着业务的发展相信这些问题大家都会遇到。而解决问题的过程或多或少的会用到上面的设计原则。 一老的业务架构 - MVC架构 很多同学开始写业务的时候基本都会先建表然后生成CURD最后再堆业务逻辑从DAO-Manager-Service-Controller一路写到底。在业务小的时候这种架构非常的简单实用可以快速的开发上线。 但随着业务发展人员不断增加老的架构难以支撑业务的发展稳定性和效率受到极大挑战。蛮荒时代已过精耕细作的时代到来急需一种更合适的架构来支撑业务的发展。 以闲鱼的详情页举例在业务初期详情的样式只有普通的开价宝贝一种但随着业务的发展演变出拍卖、免费送、租房、玩家等细分领域的商品详情页我们将细分领域的业务命名为“垂直业务”。 图2闲鱼详情页业务演变  此时还不断的在老的业务逻辑里添加新的业务逻辑导致所有的详情业务逻辑堆在一起。于是乎会出现下面的场景 1今天A详情业务线的同学加了段逻辑挂了影响了所有业务线的同学 2B详情业务线的同学想做单独的监控、缓存、降级等做不到啊大家的逻辑在一起改造成本太高 3C详情业务线的同学本想只关注C详情业务逻辑发现所有业务都在一起不得不将所有业务都理清楚一遍 4D详情业务线的同学发现前面的业务逻辑太复杂为了将影响面减少到最小找了一个认为最安全的地方加了一段D详情业务的特殊处理。 图3:详情页堆逻辑代码 有人可能会问堆逻辑正常的啊加几行代码业务就上线了互联网提倡的敏捷开发当然是怎么快怎么来。但敏捷开发 ! 提需求 编码 发布加几行代码交付业务上线可能会带来眼前的收益但一直这么下去代码会越来越臃肿没有设计和文档沉淀的系统难以维护出故障只是时间问题。 二新的业务架构 - 业务隔离 领域建模 吉德林法则讲把难题清清楚楚地写出来便已经解决了一半。 老的架构的问题归纳起来讲 1.业务没有做隔离所有的垂直业务逻辑都堆在一起互相影响。 2.详情页业务足够的复杂却没有统一的模型形成统一的认知。 因此架构的设计方案就着重解决这两个问题。 2.1 业务隔离架构推导与设计 一个业务有多种形态的实现很容易对应到设计模式里的策略模式。最粗暴的方式每个垂直业务都自己实现详情页。 图4 使用策略模式隔离每个业务的实现 这种方式业务虽然隔离了但维护成本极高添加一个通用的功能所有业务都需要添加一遍。 因此需要将共性内容不变的部分抽象出来将变化的部分由各个垂直业务去实现。 图5抽象出共性(不变和特性变的内容 这种方式解决了业务的隔离共性的内容统一维护变化的部分由各个垂直业务独立维护。但此时所有的业务团队还是在一个应用工程里写业务代码会出现如下场景 1)开发阶段各业务线都在这个应用里拉取一个分支进行开发集成部署时代码冲突难以避免。 2)A业务线添加了一段自己业务线的逻辑部署失败了导致其它业务线也无法使用。 3)N业务线不在自己的团队内属于外部合作团队如何添加该业务线的逻辑。 这些场景存在的原因在于业务代码虽然隔离了 但人员的开发过程并没有隔离。有如下3中方法可供选择: a. 将共性的内容打成二方依赖包每个垂直业务依赖这个二方包进行独立应用开发。 这种二方依赖的方法最常用但在二方服务里添加一个通用功能的时候要告知所有业务方都升级二方包还要发版升级的成本高。 图6.a 共性内容打成二方包 b. 垂直业务独立应用开发然后将代码打成jar包再集成到共性业务应用里一起部署。 该方法依赖关系跟方法a相反但部署方式不够灵活。如果要实现垂直业务的独立部署改造成本太高需要做类隔离budle隔离等。 图6.b 垂直业务打成二方包 综合a和b的优点将共性的业务独立部署垂直业务既可以独立部署也可以写在共性内容应用里。当调用某个垂直业务实现时可以自动路由到具体的垂直业务实现这个垂直业务实现可以是一个本地调用也可以是一个远程调用。这样垂直业务的开发人员就可以在自己的应用中开发、部署、运维解决开发人员的隔离问题。 图6.c  互不依赖部署方式可选 至此业务的隔离开发人员的隔离问题都已解决。但该架构方案显然不只有详情这一个场景可用其他类似的业务场景也有相似的问题。因此架构的代码不能与业务的代码耦合在一起需要将架构的代码独立出来形成通用的技术工具以应用于所有类似的业务业务开发应该只关心业务的事情。我们特地为此开发了一个多实现“业务隔离”路由工具最终的隔离架构设计图如下. 图7: 总体架构图。 2.2.领域模型在详情页的使用 隔离的问题解决了再来谈谈详情页的领域建模。 为何需要领域建模好多java开发的同学大都会遇到这样的问题1一门OO(面向对象)的语言写出来的代码都没有OO的感觉到像是过程式的代码面向对象的思想基本没有使用到。2虽然代码满足了业务需求但从代码中完全看不到业务领域的影子业务领域和代码是脱节的。3随着业务的越来越复杂里面的依赖关系梳理起来非常困难业务模块没有边界可言。 为了不给后人挖坑为了解决详情页复杂的逻辑为了让代码更有范为了让接手详情的同学都有统一的业务领域认知因此决定对详情领域进行领域建模。 图8: 领域驱动设计-模型关系总图 Eric Evans的那本《领域驱动设计——软件核心复杂性应对之道》经典书籍大行其道十几年网上关于领域建模的文章也是浩如烟海自顶向下、自底向上、四色原型建模、问题空间领域模型抽象方法论也非常的多。但这些文章和书籍要么谈论理论概念要么谈论建模方式对初学者来说看完之后还是写不出相应的代码。 所以本文不在重复的去讲领域建模的概念直接通过闲鱼详情页这个业务场景讲述建模的步骤、DDD的代码展示给读者一个更直观的参考。 2.2.1 详情页领域建模 闲鱼详情页是一个纯展示的页面用一句话可以概括为“详情页是包括商品、卖家、买家、鱼塘、认证、互动等内容的信息聚合展示页” 。 这里我们使用四色原型建模法进行建模。上面的这句话最骨干的内容为详情页是一个“信息聚合展示页”瞬间事件。 图9: 详情页是一个信息聚合展示页 骨干内容定义好后为了更好的描述详情页是什么需要补充一些实体对象详情页主要包含商品、卖家、买家、鱼塘这些实体人-物-地点。 图10: 详情页中包含的主要实体 在此基础上进一步的进行抽象用户实体中有卖家、买家这个角色存在鱼塘实体中又有塘主、塘民角色存在塘主也是塘民所以塘主应该继承自塘民。加入角色后的模型如图11所示 图11: 详情页中的角色 最后再把一些描述信息放进去 图12: 模型中补充描述信息 有了模型的设计再转为类图设计。根据模型的抽象详情页是信息展示的聚合因此它是个聚合根包含了商品、卖家、买家、鱼塘这些实体信息。 商品信息描述里又有视频、图片、文本、互动等信息。视频、图片可以抽象为媒体信息。使用UML设计出最终的类图如图13所示 图13: 详情页类图结构 2.2.2 DDD代码展示 在实现详情页时依据的是DDD中的定义。DDD中最主要的内容包括entity、value object、aggregate、repository、factory和service 如图8所示 以及Infrastructure, Domain, application和User Interface 分层结构如图14所示 图14 领域驱动设计分层架构 Infrastructure主要用于持久化数据的读取和写入Domain为领域层提供领域信息这是业务的核心所在Application是很薄的一层没有业务逻辑用来协调应用活动User Interface负责用户信息展示。将这个分层结构映射到工程结构如图15所示。 图15DDD领域建模工程结构 这里的Applicaiton层没有业务逻辑只作为二方服务对外提供。此外工程结构中没有写User Interface层因为该应用是以二方服务提供当然如果提供REST服务则可以写在这一层。 多数的用户对MVC架构比较了解因此图16对比了DDD的分层架构和MVC的架构以做参考。 图16DDD分层对比MVC分层 根据上文的模型抽象领域对象主要有 ItemEntity, SellerEnity, BuyerEntity, FishPoolEntity并通过详情页聚合根DetailAggregate聚合。 图17: 详情页聚合根 在图15应用结构分层中有3种类型的数据对象DO对象表示持久化的数据对象 Entity为领域对象DTO为对外的传输对象。 首先通过领域层的Repository调用基础设置层的Dao读取DO结构再使用Convertor转为Entity领域对象。 图18: Repository的定义 图19: Converor转化器的定义 领域entity处理各自的领域业务逻辑然后通过领域层的DetailService对聚合根DetailAggregate进行整体详情页业务领域处理。最后转为DTO传输对象提供对外服务。 三: 总结和思考 本文从详情页业务出发当业务越来越复杂时如何做业务的隔离做开发人员的隔离以及如何通过领域建模形成统一认知。给大家提供一个可行的参考。 但没有任何一种架构可以适用于所有的场景也没有任何一个架构是最优的所谓架构都在解决“边界”的问题。因此都需要从实际的业务场景出发明确出问题的边界在哪里要达到什么样的目标再遵循一些基本的原则和方法基本都能够设计出符合自己业务特性的架构。 接下来将会给大家分享一篇从不同的视角出发进行的业务架构设计。 原文链接 本文为云栖社区原创内容未经允许不得转载。