前言
去年11月从之前的业务部门调动到业务平台之后，团队的重心与目标都发生了不少的变化，之前的团队主要服务一个业务方，业务的目标相对比较重要，对于技术人员的业务sense，产品sense要求比较高，会要求从业务发展与规划方面入手对技术进行布局；而业务平台是服务整个集团的所有业务，属于比较底层的平台，对业务的KPI感知不是特别明显，而对于平台的稳定性与扩展性要求比较高，需要平台能沉淀出可复用的能力，同时可以方便灵活的定制，甚至能开放给业务团队自助开发，对于技术的应用架构也提出更高的要求。
目标
《架构整洁之道》中定义应该架构的目标：减少资源的投入。其中，资源的投入包括整个研发的流程，需求的评估、设计、开发、测试、上线、维护等。对于平台来说，这个目标非常合适，面对诸多业务方，不断新增的需求，能够减少资源投入甚至无需投入（业务自助）才能更好的支持业务发展。而对于具体的业务方来说，上线的时间是最重要的，而往往一些新的业务的诉求比较特别，平台能力无法直接满足，这个时候为了快速上线往往使用一些临时方案。作为业务平台，既要能提供插件式的功能也要支持功能的沉淀，类似操作系统能够支持软件的按照又要定期的升级系统提供新的功能。
方法论
为了实现功能的复用，让应用可以类似积木一样搭建起来，需要做的两方面，第一是减少功能的外部依赖，保留功能的业务核心逻辑；第二是保证功能的原子性。
其中第一点也保证了功能的扩展性，例如一个翻译功能，核心逻辑在于翻译，而不在于文本的输入输出，保留核心可以让功能在标准输入上使用也可以作为服务进行封装。例如下图
当面对业务诉求时，先停下来思考下应用的每一层应该如何划分，尤其是领域规则与应用业务规则之间。上图的右下角部分说明了层之间的交互，其实就是依赖倒置。
而第二点涉及到灵活性与便捷性的权衡。如果提供的功能粒度太粗，复用起来比较方面，但是不利于扩展。如果提供的功能粒度太细，刚好相反。功能粒度可以通过不同的层级来提供，领域规则提供原子能力，业务规则提供通用复用能力。
功能的复用主要是利于减少开发与维护等环节的资源投入，而对于需求，设计等可以通过可视化的方式将应用的功能展示出来，这样很好解决评估需求的资源投入以及人员变动带来的风险。
其它
本文只是一个应用架构的粗略思考，后续会对应用架构的步骤进行分开总结，方便后续实践过程中的落地与反馈。
