业务篇

短信在实现的逻辑上，也遵循消息中心的基础设计，即消息生产之后，通过消息中心进行投递和消费，属于典型的生产消费模型；

实践策略：基于行业趋势和业务周期的整体考虑，非核心业务全面集成到低代码平台中，将核心业务的边缘流程，以实践的方式迁出小部分到低代码平台中；

如果你看到这个话题，并不知道是什么意思，那么祝贺你，安安静静的当个小码农也挺好；不过我敢说，随着职业生涯的慢慢发展，大家都得碰到，到时候就细细体会吧；

开始想聊这个话题的时候，我是打算放弃的；因为这个话题涉及范围之广，内容之多，让我犯怵；近几年，待过两家公司；一家经历过重构，另一家也打算重构..... 其实要下定决心，推翻重来，是一个很有勇气的决定

订单业务一直都是系统研发中的核心模块，订单的产生过程，与系统中的很多模块都会高度关联，比如账户体系、支付中心、运营管理等，即便单看订单本身，也足够的复杂；

活动作为运营的手段，根本目的是为了更好的连接产品和用户，所以很考验运营方案的策划，在活动的生命周期内完成对业务指标的达成，比如新用户流量，老用户唤醒等；

在字典服务中提供的枚举值，根本目的是为了确保数据值的统一性，尽可能的避免同一个信息存在两种方式描述。

对于客户相关的系统来说，不管是偏向数据的CDP平台，还是偏向销售管理的CRM应用，其基础能力需要对客户的档案信息进行不断的维护，以提高客户数据的准确性。

用户身份的全局统一标识至关重要，用户实体在不同业务线所产生的行为数据，通过唯一序列号进行识别，这样进行用户分析时看到的画像比较全面；

消息通知的流程设计，在各个业务线中通过消息中心提供的接口方法，将不同场景下的消息内容提交到消息中心，消息中心进行统一维护管理，并根据消息的来源和去向，适配相应的推送逻辑。

通常在业务体系中，都会或多或少的涉及到支付相关的功能；对于一些经验欠缺同学来说，最紧张的就是面对这类支付结算的逻辑，因为流程中的任何细节问题，都可能引发对账异常的情况；

做这些业务设计时，核心思想是：把常用的逻辑进行封装，流程设计为可配置，这样即可在一定时间内应对业务的需求和变化，降低开发成本的支出，从而使研发更侧重核心业务的管理和抽象封装等内容。

在系统开发的过程中，必然存在耗时极高的动作，是基于请求响应模式无法解决的问题，通常会采用解耦的思维，并基于异步或者事件驱动的方式去调度整个流程的完整执行。

采用合理的策略去管理资源的权限并不是一件简单的事，通常随着业务和系统的不断扩展，对权限体系都会带来直接的影响，所以在做结构设计时，需要相对复杂但又要避免过度复杂。分布式系统中，通常从系统层、组织架构、