07 | 可复用架构：如何实现高层次的复用？

王庆友

你好，我是王庆友。在前面几讲中，我们讨论了如何打造一个可扩展的架构，相信你对架构的可扩展有了一定的了解，而架构还有一个非常重要的目标，那就是可复用。所以从今天开始，我就来和你聊一聊，如何打造可复用的架构。
作为开发人员，你对复用这个概念一定不陌生。在开发过程中，我们把系统中通用的代码逻辑抽取出来，变成公共方法或公共类，然后在多个地方调用，这就是最简单的技术上的复用。
但一开始，我们不会过多地考虑复用，当一个新项目过来，我们会选择最直接的方式来实现，结果往往是欲速而不达，比如说：
好不容易搞定了一个项目，接着又有新的类似项目过来，我们又要从头再来；
项目的代码是定制的，项目结束后，系统维护的噩梦刚刚开始。
如果项目缺乏沉淀，每个项目都是全新的开始，出现这些情况，一点都不意外。而要想解决这个问题，我们一开始就要考虑系统的复用性。
复用，它可以让我们站在巨人的肩膀上，基于现有的成果，快速落地一个新系统。
那么，我们在做架构设计时，如何实现系统的高可复用呢？
今天，我就针对复用这个话题，首先和你介绍一下，复用具体都有哪些形式；然后，我会针对最有价值的业务复用，带你了解如何划分服务的边界，让你能够在工作中，设计一个可以高度复用的系统。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文介绍了如何实现高层次的复用架构，包括复用的分类、复用程度以及基础服务边界划分的原则。作者强调了复用的重要性以及如何在架构设计中实现高可复用性。在技术复用方面，讨论了代码级复用和技术组件复用，指出它们的复用价值相对较低。在业务复用方面，介绍了业务实体复用、业务流程复用和产品复用，强调了产品级的复用程度最高。此外，分享了服务的一致性原则和正交原则，以及落地基础服务是实现业务复用的有效方式。总的来说，本文为读者提供了深入的技术思考和指导，帮助他们更好地理解复用的形式、价值和落地方式。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《架构实战案例解析》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(27)

最新
精选

四喜
置顶
老师请讲讲订单服务，订单小票包含了价格，价格涉及到优惠信息。价格信息来自商品服务，优惠信息来自促销服务。订单服务从数据上依赖商品服务、促销服务。请问这个订单小票，是订单服务的功能呢？还是上层聚合服务的功能呢？订单服务本身负责什么呢？
作者回复: 这个比较复杂，大家不要陷入这个具体的业务里面。具体讲，就是 1. 上层应用调用促销服务，把购物车的商品信息和用户信息传进去，返回的是最终订单金额，以及因为各个优惠减免的金额。这个是促销服务结合内部的促销规则记性计算 2. 然后上层应用调用订单服务，把订单的信息，以及优惠结果传进去，订单服务负责在数据里保存优惠结果。所以是上层应用调各个基础服务，基础服务之间不会互相调。
2020-03-12
4
11
果然爸爸
像用户服务这种基础服务，所有其他业务服务都会依赖，按照老师的说法，基础服务最好不要相互调用。这种情况，怎么处理，把用户数据冗余到所有服务吗？这样数据同步会是个比较复杂的问题。
作者回复: 在基础服务的上层聚合各个基础服务，比如应用通过订单服务拿到订单的用户id后，再调用用户服务获取用户详细信息，而不是订单服务内部去调用用户服务。
2020-05-16

3
AngryApe
王老师，请教一个问题：在架构设计的时候服务一般的分层的，基础服务层（业务实体），共享业务层，应用服务层，按这个结构的话是否允许应用服务层直接调用基础服务层？比如一个简单的查询优惠券详情，没有什么复杂的逻辑，这时候应用层是否应该直接调用基础服务层？
作者回复: 可以跨层调，你这里的共享业务层是聚合业务层吧? 基础业务层提供的就是共享业务
2020-03-17

3
DullBird
商品价格的例子，有点疑问。商品的录入的时候基本价格应该是属于商品域的。但是实际展示的时候涉及到营销活动，优惠活动。这个销售价又属于营销或者价格域的。其实这里商品有时候也会冗余最终的销售价(会有一定延迟),这样在搜索商品的时候。基于价格排期才比较方便。
作者回复: 价格规则复杂情况下，往往有独立的价格服务，比如同一个商品有app价，团购价，pc端价，线下价，促销价等等，涉及复杂的优先级排序
2021-06-06

2
Geek__b3bddc1474fa
课题是：如何实现高层次的复用？但实际只是介绍了不同类型复用，大篇幅在介绍，没有讲解怎么做到。结论是没有干货
作者回复: 嗯，专栏这篇文章从实际出发，建议复用层次“高到" 基础共享服务复用就可以，后面针对基础共享服务设计做了很多深入介绍，注意连贯起来阅读和理解。
2022-08-12归属地：上海


ezekiel
老师您好！在服务的完整性原则中，套餐商品的价格应该由商品服务提供，商品服务应该访问优惠服务获取信息，然后返回调用方法，但是在下面正交原则中，基础服务是不应该访问其他服务的。这里有些困惑
作者回复: 这个应该是商品聚合服务，从领域来说，职责属于商品域，商品域包含商品聚合服务和商品基础服务，商品基础服务符合正交原则。
2021-10-09


jun
可以冗余一部分其他业务领域数据，但这部分冗余数据得有2个特点：1、不需要实时变化的数据 2、不需要保持数据一致性的信息；
2020-04-01

14
萧
可复用架构技术复用：工具层面，复用价值较低代码复用：算法，SDK之类技术组件复用：Redis、MQ、Dubbo 业务复用业务实体复用：业务领域，订单、商品、用户业务流程复用：业务场景，下单流程产品复用：整个系统，SaaS、PaaS 基础服务边界的划分：完整性原则：要保证服务数据完整、功能全面，这样才能支撑一个完整的业务领域。一致性原则：服务的数据和指责一直，谁拥有较多的数据，谁就负责提供相应的功能正交原则：服务之间可以用数据的依赖关系，但没有接口的调用关系
2020-10-12

5
LiuHu
冗余的目的是保证自身业务的一致性、完整性，原则是冗余的信息越少越好，不是为了方便搜索查询而冗余一些业务领域外的不必要信息。对于搜索查询，交由专门的聚合查询服务。对于可变的信息只冗余关联信息的ID，对于不可变数据冗余可以具体信息。
2020-04-06

3
Din
冗余其他服务的数据时比较常见的做法，这样可以减少和其他系统数据的交互，提高服务性能。不过数据一旦冗余，就会带来数据一致性的问题。
2020-03-06

2

收起评论