背景
最近在做 BI-统计图查询层重构(java应用层分析查询), 自己也在设计的这个过程中结合过往的经验在思考:
1、到底什么是好的架构设计？
2、好的架构设计应该具备哪些特征？
3、设计完成的方案能否平稳落地？
4、团队协同开发的时候是否方便、易用？
5、后期业务增长、功能迭代的过程中是否又要推翻原有的设计？
带着这些问题 在此次重构架构设计的过程中反复思考，反复实践，自己总结了一些方法论，下面与大家分享一下，供大家指正与参考。
适用人群 重点适配高级开发人员。 但因为是总结方法，产品、测试、开发人员均可参考。
一、我心目中好的架构设计
我心目中好的架构设计，应该具备以下几个重点项(权重由高到低)
1、规范边界
使用严格的技术手段，依据业务模型，规范功能职责、规范业务边界。从逻辑上(业务模型)和物理上(文件结构)共同进行规范。
--好影响:
因为指责清晰，所以后续丰富功能的过程中，能保证功能内聚，每次功能迭代的过程中可以通过小范围重构使系统更健壮。在经历1-2年的迭代后，系统业务边界依然清晰，功能足够内聚。
2、中台设计
架构设计上要适当的技术驱动业务，系统功能应通用。
设计过程中要先从业务入手(此阶段是业务驱动技术)，收集所有功能(通用功能 定制化功能)，然后设计业务模型，之后进行架构设计，此阶段就是要技术驱动业务，我的系统应该具备什么能力，可以支持什么功能，现在业务没有提到的功能是否也能支持，这些业务没有涵盖到的功能只是实现预留，暂时不给前台提供此功能而已。这样系统的设计对于后台来讲才是符合逻辑的，健壮的，有依据的，而不会因为严重的功能定制化导致系统结构零散，没有规矩、没有规范，导致系统越来越臃肿，最后到达不能迭代的境地。
--好影响: 系统功能健壮、有章法、有规矩。
3、支持拓展
总体宗旨就是因为易拓展，所以易维护。功能要良好支持拓展，包括横向拓展、向上聚合拓展、多组合复杂场景拓展。(此项结合具体业务去看，例如此次重构就是复杂在多场景、多条件组合相互影响上。)
--好影响:
具体实现可采用策略模式、多条件组合策略 结合 模版方法进行设计，做到核心功能统一、定制化需求相互独立、功能聚焦、功能易理解等。从而干掉if else-if else这类严重影响系统维护的代码实现。
4、迭代简单
大道至简。技术架构设计可以复杂，可以精巧，可以不易理解，但是需要把业务逻辑实现屏蔽在架构设计之外。在业务逻辑的实现上一定要简单、简洁、易懂，用最简单、最高效的代码，实现逻辑。
主干流程打通后，或者现有业务支持成功后，后续加人介入开发，即使实习生或者初级开发工程师也能快速接入开发。而且针对不同职级开发人员，可结合业务及依据架构设计，分配不同难度工作。
--好影响:
架构搭建完成之后，系统维护不严重依赖核心设计人员，做到核心设计人员和系统解耦，同时系统迭代效率可横向拓展，加人即可增加系统迭代速度。
后记:
此架构设计文为【专题系列】，大致一周更新一次，后续将结合现在进行的重构工作，围绕此项目周期，从重点场景设计、落地实现、代码实现细节、失败案例分析、测试阶段及线上暴露问题、灾备方案、持续优化等方面进行持续更新，理论结合实践进行设计历程记录，供大家参考。
