- 讨论系统设计方案
- 技术文章审稿
- 讨论会议形式与机制
会议建议：
- 讨论效率质量方面共性问题，这些问题应由谁或哪个组织提出和整理出
- 暴露的问题根据不及时，缺乏重视和反馈
移动组件方案：
为什么FLAG巨头构建了那么多基础能力，比如React，Yoga，Flutter，GraphQL等，技术上完全具备能力进行组件化动态实现。目前国内也只有阿里往这个方向走，但仅局限于APP部分能力，一个可能的原因是只有电商这类应用，存在流程型很强，分流需求明显，页面变化频繁的场景才有类似的需求。比如Google和FB基本都是单页面架构，微信这种也基本是这样，更倾向于在一个页面上做细节调整，而不是组件化级别构建。
重复建设问题：
需要制定一套统一规范，在整个部门推行。避免重复建设，避免部门内部在流程规范上形成不同的标准。
OKR问题：
OKR编写上，一些目标和关键点结果不够明确，或者目标太大，或者稍显冗长。OKR目标需要更具体明确，且能在一个Q里面完成。如果目标太大，可以考虑拆解成几个小目标，否则一个Q做不完，由会出现在下一个Q里面，这样会影响到OKR的执行效果。同时一个Q里面目标不应该太多，一个O的结果KR也不应该太多，KR应该更好量化。
与业务中心多沟通：
平台框架组和技术保障组与业务中心不同，两个组大多数工作横跨各个业务中心，两个组应该多和业务中心沟通，防止闭门造车。
平台化：
平台化很大程度上要解决业务开发的痛点问题。要加强与业务团队多沟通。在进行订单可视化可配置可隔离项目中发现，订单同学和平台框架组同学对平台化相关概念理解存在不一致问题，比如业务活动和域服务的关系，业务域和业务子域的关系，及业务子域和扩展点之间的关系等，很有必要理清这些。
- 调研平台化方案 oasis和BDF，包括业务域，功能域，业务活动，域服务，扩展点概念，难以明确理解这些概念，在开发时造成困惑。需要简化和理清概念，给出明确定义，确保各方理解无误。
- 讨论流程引擎设计
扩展点概念：
业务方对于配置型扩展点的使用有疑问，比如静态代码分析时有不足以分析出完整业务流程，需要运行时支持。作为业务架构师，要在业务和平台框架组之间发挥桥梁作用，为把架构更好落地业务方做好衔接和沟通。
如果更好熟悉项目：
项目文档不全，缺少总结性文档，使得新人对业务逻辑的理解比较困难，只能通过逐步参与需求开发进行深入了解。
Token服务化：
关注流量，与高并发场景。
共建项目：
- 工具类统计
- 研发小组问题排查工具
微分享：
技术提效，稳定性的知识，工具，系统。
思考业务架构师定位及职业发展：
总结起来： business architect = 2 control + 1 landing 2 control = full stack technology + business model 1 landing = product landing
X2leader和业务架构组都需要具备产品思维。产品思维包括如何收集，如何设计，如何推广，特别是一些偏技术驱动的项目，需要leader成为一个懂技术的产品经理。
流量运营平台：
核心是应用的快速搭建及效果评估，偏业务的方向是广告投放变现相关内容。偏技术和工程方向应该是应用响应式构建与投放平台。
库存系统：
在正常的领域划分方式下，我们会划分出商品，订单，营销，支付相关的领域，如果是库存系统我们一般视为核心域下面的支撑域，但是在一个更广纬度的交易系统来说，库存本身也算是一个核心域，其他领域下比如商品，积分，奖励金等在库存能力上基本表现雷同，系统上可以复用一个库存系统，这是平台化背景下对于领域划分的一个挑战。
关于代码质量：
代码质量往往是系统高速发展期间需要谨慎对待的事情，保持速度的同时保证质量。否则坑就在那里，看谁掉进去。每一个解决方案在满足需求的同时，要站到整个项目未来发展的角度去考虑，以平台化的思维做需求，可以将平台建设工作拆分到不同的需求当中去，这样保证在需求迭代之后，平台大势基本完成。而不是在多个需求沉淀之后，再进行系统重构重建平台，这样代价巨大几乎是不可承受之痛。
设计方案时要做的事情：
需要考虑止损方案，开启流量验证。新项目新接口上线要做线上引流，或者流量录制进行压测，可以很好的进行系统预热。 生产环境要抱有敬畏之心。
来源：oschina
链接：https://my.oschina.net/u/1000241/blog/3187944