08 | 可复用架构案例（一）：如何设计一个基础服务？
订单业务架构
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了如何设计一个基础服务，以订单服务为例，详细讲解了共享服务的落地过程。作者强调了服务边界的划分和功能的抽象设计是核心，通过订单服务的功能和不包括的功能，清晰地定义了服务的边界，避免了后续的争论。文章重点介绍了订单服务的内部设计，包括基本信息管理、订单优惠管理和订单生命周期管理等功能。作者强调了对内部数据模型和外部接口进行良好的抽象设计，以保证服务功能的通用性。此外，文章还探讨了订单状态管理和订单服务接口定义的具体实现方式。通过实际案例深入浅出地介绍了如何落地共享服务，实现业务能力的复用。整体而言，本文为读者提供了清晰的指导，帮助他们理解如何打造一个可高度复用的共享服务，掌握核心的边界划分和内部抽象设计的技能。
《架构实战案例解析》，新⼈⾸单¥59
全部留言(14)
- 最新
- 精选
Jxin置顶
1.碰巧也是做订单系统的。 2.目前接管的订单系统是一个开发了四五年的单体订单系统。 3.没有边界划分，以往的实现，基本就是开发将产品的业务逻辑翻译成代码。现象就是部分拆单策略非常复杂，所有本该外部系统承接的业务逻辑都由订单组完成。这就导致你想维护订单组，支付，营销，会员，商品你都要懂业务。（起步简单，可能这些现在的分组都是那么几个人来完成，但随着业务线的发展，各组的业务都膨胀了很多，已经不是个人短时间能够掌握的）。 4.代码耦合非常严重，一个商品组的表对象do，会在各个组的api包里面被依赖，相关的业务逻辑也严重依赖该do。牵一发动全身，常常因为一个字段的调整开很久的会议。 5.代码实现没任何扩展性和灵活性，大量逻辑判断依赖入参状态，导致从单体转多元输入后，一个方法动不动就上千行代码，大量根据数据元做逻辑跳转的代码。 6.职责模糊，功能复杂，代码耦合高，实现逻辑基本硬编码没有扩展的能力，没有任何单元测试。 7.现在需要该项目能灵活支撑多元业务的接入，基本就是单体往saas发展了。我能想到的方法都需要较大成本，因为最小的组成单元“策略”，本身的实现不具备可灵活复用的特性，必须重构其实现方式。但如此一来，成本太大。领导是接受不了的。作者回复: 感觉你这个不仅仅是订单服务，而包含了订单之上打的oms系统，如果一开始各个基础业务划分的好，系统整体就很好调整，下一讲说的是现有系统的服务化改造，也许对你有用
2020-03-098
J.Smile老师好，订单服务在异步通知应用的时候使用的技术我觉得不一定非要mq吧，只要应用把自己的通知url告知订单服务，订单服务负责在信息变动时进行推送就可以了，这种更简单一些，不过可能可用性不是很高而已。作者回复: 你这种说的是url回调，这也是一种方式，在支付里用的比较多，收到第三方平台支付成功后，支付服务回调应用系统提供的URL完成通知。 这种方式比同步调用耦合性低，比消息通知耦合性高一些，并且调用不成功，要重试，服务要做的事情要更多一些。 如果针对不特定的接收者，消息通知更合适，解耦更彻底一些。
2020-03-0946
小洛请教下老师 1、关于设计两个状态字段管理订单主状态和子状态，可以主状态是个单独字段，而子状态放在扩展字段吗？那么订单还承接按照子状态纬度的查询 2、关于订单主状态，基本状态是不可变的，比如支付，下单，结账（结束）但是我们公司的业务就是结账状态有个逆操作反结账，然后还可以不停地在原订单的基础上再加菜，这样的设计合理吗作者回复: 1. 既然子状态是显式的,最好有明确字段保存。 2. 针对这种情况，可以考虑结账不是订单的结束态，而是结账后，过一定时间自动关单，变成真正的"完成"状态。
2020-03-165
中国合伙人我想问一下，订单模型不一样，我们经常通过扩展字段存储差异化数据。那在哪解析扩展字段？基础服务负责解析这些差异字段吗？这里要怎么设计不同业务类型订单查询？作者回复: 如果扩展字段是通用的，订单服务会把这部分逻辑落进去，如果是某个项目专用，订单服务支持落数据就可以
2020-03-094
如来神掌数据如何存储? 比如A应用产生的数据和B应用产生的数据，在数据库设计上如何设计和存储呢？作者回复: 如何是服务化设计，A应用和B应用的数据落在不同数据库。
2020-11-302
Sam_Deep_Thinking请问一下，针对c端的下单接口，是由订单基础服务来提供还是由订单的聚合服务来提供？如果是基础服务来提供的话，那由于下单的时候，还是需要调用其他服务获取数据，进行订单数据落地，这就违反了文章中提到的原则，如果是聚合层来提供下单接口的话，那么基础服务落地订单数据时，聚合层就必须传递订单所需要的所有数据。作者回复: 由上层的聚合服务提供，内部调用多个基础服务。
2020-06-111
蓦然回首老师好，针对订单服务，如果要支持的业务模型不一样，比如商品、酒店、外卖，订单接口比如下单，是使用一个接口还是按业务分成多个接口比较好？底层存储是按业务分开存储，还是通过通过抽象和扩展放到一个库中好呢？作者回复: 这个要看这些不同订单共性内容多不多，包括数据模型和业务逻辑，如果差异不大，整合在一起，如果差异很大，没必要强行整合在一起，理解起来困难。
2020-04-031
AYOU老师好： 1.基本信息管理里面有用户信息，这个用户信息是用户系统的用户基本信息吗？上层系统下单组装用户信息时，订单系统只存用户id还是存一个用户的基本信息？ 2.一般退货的流程是在订单系统做吗？作者回复: 是用户基本信息，订单系统一般只存用户id,多存信息就冗余了，简单的情况下，退货单也在订单服务里管理，比如餐饮外卖。复杂情况是有单独的退换货系统，比如电商
2020-03-1121
探索无止境可惜只有22讲，每一讲都有收获2020-03-099
tt可复用的两个点：清晰的边界划分和抽象的内部设计。 1、对于边界划分。在服务的设计之处，总是会现有一个头脑风暴、各方需求裹挟的发散过程，然后随着设计的进行，必需经过收敛，所以我觉得界定服务不做什么更有实践意义。同时，服务功能越单一，越利于复用。 2、对于内部抽象设计。 我听完本科，觉得抽象设计还是紧紧的围绕到目前为止的不变的核心：数据和规则（这里特制对外的服务）。 对于数据，不仅要保证需要的数据要覆盖全面（基础信息、组合信息、外部系统使用的信息——之前的可也讲过，服务是相互正交、互不调用的，但可以共享一定的数据），而且要考虑数据是动态的（比如订单状态的变化），变化就涉及到状态检验规则。这就又涉及到了数据的全面到底是什么含义？是胡子眉毛一把抓么？不是的，是应该抓主要矛盾（比如订单分为基本状态和子状态） 不主动调用外部，并不是说和外部没有信息交互。这时，使用消息队列进行消息通知自然是一个好的选择，使得内外部解耦。 进一步，订阅发布模式使得发布消息的实体和接受消息的实体解耦了，双方只需要面对消息本身即可。这是一个理解消息队列的高级的视角。2020-03-0935
