技术架构和组织构架的关系
技术架构合理性的基础是需要配套的组织合理性，脱离组织合理就无最佳系统架构
近日对技术架构以及组织架构的理解更深入了一些，真实遇到了组织变化引起的架构合理性的挑战。先说一下当前门店系统的架构，一年前经历过一轮CQRS改造及维护权下放，（如不懂CQRS可自行翻阅领域驱动开发书籍）。下面分别先说维护权下放和CQRS改造。
维护权下放
门店把相关属性按领域划分，分为如下几个领域：
- 基础门店信息，包括商户名、品牌、电话等；
- 店铺运营，包括营业状态、营业时间等；
- 配送，包括起送费、配送费以及相应的规则等；
- 资质；
- 订单，包括预定时间、是否支持预定等；
为什么会如此划分？因为研发资源单点，如上领域的所有需求都由门店运营研发支撑，每月产品需求在50+以上，研发资源固定却有这么多需求只能按优先级PK，不仅产品在优先级协调上花费大量时间，研发团队上，门店的研发超负荷运转，但各自领域的研发有力无处使。这里提一点，很多功能都是B、C联动，比如门店系统设置好预定时间，C端根据条件展示相关信息。
所以运营权的下放将所有研发资源都调动了起来，订单领域的同学不需要等门店同学一起开发，自己就能维护门店上的订单属性并且数据在C端应用。
CQRS改造
在经历过很多次运营操作或者后台任务导致门店整体性能恶化，C端无法访问商户数据后，也趁着维护权的下放将门店信息的写及读系统完全分离。
重新改造了原有一体化的系统，剥离出门店的所有写操作，原系统通过消息的方式从各领域获取数据变更消息并查询最新的数据写入数据库及redis。此外单独构建了商户查询系统仅处理对外大流量商户数据查询。
最终架构
门店CQRS改造.jpg
近期问题
该系统在整个中后台团队中稳定运行了半年，但是18年底进行了一次组织调整，交易域离家出走，并到研发中台成立订单中台，此外业务不断发展，新零售成为重要的业务之一。在对接新零售的门店交易属性时遇到了很大的冲突，各自诉求如下：
新零售：统一的数据写入服务；
交易： 交易工作量最小，系统简洁，且不是主数据，不应由订单维护；
门店：门店订单属性需要领域统一管理，需要走订单域再镜像到门店查询系统。
实际这里牵涉到了两个二级部门，各自部门目标不一样，出发点不一样，交易一味的追求系统简洁却不考虑扩展，新零售一味追求统一写入却忽视了这并无这样的组织保障。同样门店寻求全局最优但也是无组织保障。
所以最终方案待定，且看我后续更新，方向无非两种 ：
1、推动组织变革；
2、职责收归；
3、妥协架构
网友评论