3.1 环境搭建

相关推荐

• 7.3 实战训练（全员营销为例）

  史, 昂

  Oinone 7天入门到精通 2024年5月23日

  1.2K000
• Oinone 7天入门到精通

  5.8 商业支撑之执行域

  一、基础介绍 执行域包括两个核心一是订单的产生，二是订单的履约。往往品牌商既有自营渠道（包括2c、2b）、又有第三方渠道。那么有两种设计思路： 把第三方渠道的订单当作自有渠道的订单产生一种特殊方式，开放订单创建接口，并统一履约。 好处：简单，在3方渠道不多、且自有渠道单一，并且逻辑相识时系统结构会简单 坏处： 当3方渠道的履约方式、库存分配方式、逆向逻辑等有差异时，会让自有渠道参杂很多不相干的逻辑引入不必要的复杂度 自有渠道不够独立和纯粹，自有渠道多样化时难以支撑 把商家自营渠道假设为特殊的第三方渠道，再建立统一的订单管理系统来对接渠道订单，并完成履约 好处：交易与履约逻辑分离，对未来发展有扩展性 坏处：引入一定复杂度 我们采用的是第二套方案，整体结构简易图如下 图5-8-1 方案整体结构简易图 二、模型介绍 图5-8-2 模型介绍 核心设计逻辑 首先我们看到上图交易域和履约域有很多相同父模型的子模型，交易域和履约域的父模型在CDM的在himalaya-trade里。履约域看oms（libra）对himalaya-trade扩展，交易域看b2c（leo）和b2b（aries）对对himalaya-trade扩展。libra、leo、aries是我们对上层业务产品的命名，取自黄道十二星座 交易域是多商家平台视角设计，有自身渠道必要的履约相关信息，完成自闭环。 履约域是从单一商家对接多渠道视角设计，有渠道交易订单同步后完成履约发货相关设计，完成自闭环。 履约域的合单拆单发货设计，渠道订单只能合单为履约单不可拆，履约单可以拆单发货不可合。用m2o和o2m的组合设计来降低难度，而非采用两个m2m的设计。

  史, 昂

  2024年5月23日

  1.2K000

• 庄卓然

  从2009年加入阿里至今，经历了“三淘”时期、天猫时期、双十一，到最后的all in无线手淘时期，几乎是赶上了淘系发展的所有历史性事件。在这个过程中，每一次业务的变革都催生着技术的变迁，倒逼着我们用技术的方式去解决业务问题：在存储、IO、网络等环节满足不了淘系的业务规模时，开始去IOE，最后演化成了阿里云；当业务的规模大到不能通过简单加机器的方式去做调整、当开发的规模大到所有人在一起开发会互相影响的的时候，我们开始做SOA改造，最后演化成了业务中台；在经历了几届双十一后的巨大挑战后，我们开创了里程碑式的全链路压测；在手淘时代，为了解决动态发版问题，我们植入容器概念，搭建了可动态插拔的三层架构，一年实现了500多次的发版；为了同时满足写一套代码就解决多端开发和高并发的性能问题，我们做了weex，最后还捐给了开源社区…… 每一次的业务需求推动技术进步，而技术的进步永远会超出我们的想象！ 同为技术宅，我在Oinone身上能清晰地感受到技术演进的脉络，企业在数字化时代，需要一个能快速上手、全面设计、灵活适应且低成本的技术工具，时代的变迁推动了Oinone的诞生。Oinone是一种全新的开发方式，在数字化时代，Oinone在提升研发效率上做出的创新性“低无一体”的设计对传统软件代码开发或者无代码开发一定会有巨大冲击，这种冲击会对软件市场格局造成什么样的变化，我拭目以待。 最后，愿我们这些追光人，在时代的洪流中，都能留下一抹印迹，不辜负时代，不辜负自己。 现任阿里巴巴副总裁，飞猪总裁，曾任阿里大文娱CTO兼优酷COO、淘宝CTO 庄卓然（南天）

  史, 昂

  Oinone 7天入门到精通 2024年5月23日

  2.0K000

• 模型设计器

  史, 昂

  Oinone 7天入门到精通 2024年1月20日

  2.3K000
• Oinone 7天入门到精通

  4.2.6 框架之网络请求-拦截器

  在整个http的链路中，异常错误对前端来说尤为重要，他作用在很多不同的场景，通用的比如500, 502等; 一个好的软件通常需要在不同的错误场景中做不同的事情。当用户cookie失效时，希望能自动跳转到登录页；当用户权限发生变更时，希望能跳转到一个友好的提示页；那么如何满足这些个性化的诉求呢？接下来让我们一起了解oinone前端网络请求-拦截器。 一、入口 在src目录下main.ts中可以看到VueOioProvider，这是系统功能提供者的注册入口 图4-2-6-1 VueOioProvider import interceptor from './middleware/network-interceptor'; VueOioProvider( { http: { callback: interceptor } }, [] ); 图4-2-6-2 拦截器的申明入口 二、middleware 在项目初始化时使用CLI构建初始化前端工程，在src/middleware有拦截器的默认实现： 图4-2-6-3 在src/middleware有拦截器的默认实现 三、interceptor interceptor在请求返回后触发，interceptor有两个回调函数，error和next error参数 graphQLErrors 处理业务异常 networkError 处理网络异常 next extensions 后端返回扩展参数 const interceptor: RequestHandler = (operation, forward) => { return forward(operation).subscribe({ error: ({ graphQLErrors, networkError }) => { console.log(graphQLErrors, networkError); // 默认实现 => interceptor error }, next: ({ extensions }) => { console.log(extensions); // 默认实现 => interceptor next }, }); }; 图4-2-6-4 后端返回扩展参数 四、interceptor error // 定义错误提示等级 const DEFAULT_MESSAGE_LEVEL = ILevel.ERROR; // 错误提示等级 对应提示的报错 const MESSAGE_LEVEL_MAP = { [ILevel.ERROR]: [ILevel.ERROR], [ILevel.WARN]: [ILevel.ERROR, ILevel.WARN], [ILevel.INFO]: [ILevel.ERROR, ILevel.WARN, ILevel.INFO], [ILevel.SUCCESS]: [ILevel.ERROR, ILevel.WARN, ILevel.INFO, ILevel.SUCCESS], [ILevel.DEBUG]: [ILevel.ERROR, ILevel.WARN, ILevel.INFO, ILevel.SUCCESS, ILevel.DEBUG] }; // 错误提示通用函数 const notificationMsg = (type: string = 'error', tip: string = '错误', desc: string = '') => { notification[type]({ message: tip, description: desc }); }; // 根据错误等级 返回错误提示和类型 const getMsgInfoByLevel = (level: ILevel) => { let notificationType = 'info'; let notificationText = translate('kunlun.common.info'); switch (level) { case ILevel.DEBUG: notificationType = 'info'; notificationText = translate('kunlun.common.debug'); break; case ILevel.INFO: notificationType = 'info'; notificationText = translate('kunlun.common.info'); break;…

  史, 昂

  2024年5月23日

  1.5K000