订单系统的设计与研发

第一讲 订单的架构，设计思路

作者目前有了一些订单系统相关的研发经验，把相关的设计思路和个人的想法记录下来以便查阅，如有雷同纯属巧合，如有bug欢迎提出！

订单系统或者订单模块(是有区别的，系统是独立的，模块是系统内部的一部分，当你的系统架构达到了一定程度就会面临到拆分，这个以后会提到)的设计首先要根据现有的业务逻辑出发，提起订单就会想到商品、赠品、折扣、物流、支付、售后等等问题。但这些只是市面上的常见的订单业务，有很多我们看不见的或者不常见的业务比如说58同城的订单，或者货拉拉的订单这种比较看重下单后相关产品给客户所带来的服务，以及客户的反馈和服务流程中产生的其他业务线。说这么多的目的就是在设计订单架构的时候要考虑到目前的需求到底是什么以及要怎么设计能让他尽可能的达到通用，要考虑怎样设计能让以后的架构更清晰，便于后人维护更便于系统独立。

我目前所做的订单系统的业务线比较繁杂就用商品的类目来说涉及到实物商品、虚拟商品、到家服务、课程商品、家政服务这几大类。这就涉及到订单要做到足够大的冗余能够满足以上几个类目的商品，从架构到表结构都要足够的清晰。

首先说订单系统的架构应该怎样搞，不管是什么语言都需要对整个架构进行分层，我目前是用python来搞的就用这个来举例，可能python的分层并不如java那么清晰，但是也要尽可能的去分层这要会让后面的研发、重构或者维护非常的舒适。具体的分层就不在这细说，网上讲的很多。这里讲需要注意的，订单系统对于整个公司网络架构来说算是核心系统，那么对于它就会有很多的外部系统来获取信息，订单要尽可能做到灵活而全面，首先将自己的所有信息不针对任何系统全部吐露出去，可以按表或者其他的划分接口。要将自己的变化吐到队列中比如kafka，这样方便其他系统获取历史信息并且可为数据部门提供打点数据。整个订单系统的原则就是我是核心，要做到信息的完整全面，在内部设计上要做到灵活多变，多继承、多集成、少耦合、多冗余。一个好的订单系统可以做到支持多方子系统的同时可以无限可能的拓展自己。举个和商品系统关联的例子：公司开始只卖实物类商品后来又新增了虚拟商品，服务类商品，那么就涉及到订单系统的下单流程，此时订单能做到无论什么商品下单，可以根据类型或者其他的分类选择下单方式而不是固有的一种方式。在内部流程中封装好共有的部分，和商品交互也要做到少耦合，比如核对订单商品价格、核对库存等可以单独一个子系统去处理，这样各个系统都是独立的都只关心自己的逻辑，互相之间影响不大，这样到后期我可以随意升级一个系统或者直接替换。待续。。。。。。