公司目前以及规划的产品线基本模式都很相似。每条产品线都有一个核心系统，其他各附属产品之间围绕核心产品展开，各辅助产品之间也有一定发业务相关性，且会发生不同程度的数据交互需求。客户群体也相对固定，有着明确的上下级关系，每级都有自己的主要工作职责，但客户在选择产品的时候会根据自己的需要对核心产品及其附属产品做定制化的组合需求，每个客户也都会在标准产品的基础上产生很多细小的定制化需求。
在索引里提到开发框架要完美契合公司的产品形态，并且应该关注的是定制化、开发质量、开发效率的问题，同时还应该提供足够的基础功能来支持产品的开发。为了满足这些要求，在设计框架的时候对框架提了一些具体的需求，并根据需求设计开发了目前的开发框架。
1、对业务开发支撑的要求
1.1：满足定制化的要求。
1.2：保证质量最下限的情况下，能最大幅度的提升开发效率。
1.3：能够满足未来五到十年公司的战略要求。
2、提供的基础功能
2.1：权限模块
2.2：机构模块
2.3：监控模块
2.4：其他辅助模块
1、对业务开发支撑的要求
1、1：满足定制化的要求。
如果要做行业应用软件产品的话，这一点是最重要的一个要求了。以医疗行业为例，得益于详细的国家法律法规以及行业规范，任何一个产品的基本功能要求都能做到全国一致，但每个省、市、县又都会又自己的地方性规定，再到每个医院、地方卫建委这些具体使用部门又会有细节上的定制，甚至同一个单位的不同部门、领导之间对同一产品也有不同的理解。
这就要求产品在设计开发时要依照国家法规或行业规范进行开发，但到项目上又能根据客户的需求能够进行快速的定制化开发，提升项目的上线落地效率。最理想的项目上线模式应该是这样的。
项目开发人员在使用标准产品创建项目时根据一定规则，在只使用少量配置不写代码的情况下，就可以完成标准产品的部署。在客户没有其他要求的情况下，整个项目就可以直接上线运行。如果有定制化的要求，只需要对有要求的模块上的功能点进行开发、测试即可，该模块上的其他功能点依然使用标准版。如：某一个模块列表增加了一个查询条件，开发人员只需要根据规则修改查询项即可，其他的如列表、填报、汇总统计不需要进行任何修改。
对于已经部署运行的产品，如果有标准版的大规模升级可以做到批量升级。以公共卫生为例，2020年5月左右新冠被纳入慢病管理，如果公司公卫产品已经在一、二十家用户部署，这些用户都需要这个功能点的升级。如果可以通过对标准版程序jar包或类库的升级就可以完成功能的部署，并投入使用，那么就会是一件很好的事情了。
1、2：保证质量最下限的情况下，能最大幅度的提升开发效率。
这一点最重要的是保证质量最下限，任何一个项目开发都是要团队配合，但团队里面每个人的水平都不一样，他们有可能是刚毕业的学生、有刚加入团队还保留之前工作风格的新人。有人做东西快但质量不高，有人就特别的油监督需要费很大的精力。这个工作虽说是个综合性的工作，但拆分到框架上，框架要做什么才能保证质量的最下限。
在讨论之前先想一下质量的最下限是什么，这里我也说不好，但可以简单的列一下如基础的增删改查不能出现异常、任何异常都有可追溯的日志、业务流程不会莫名其妙的中断等等。再看上面说的每个团队成员水平都不一样。那么框架就需要去设置一个下限，任何人只要用这个框架开发的东西再差也不会差过这个下限了
1、3：能够满足未来五到十年公司的战略要求
这个要求有点务虚，公司的战略要求是什么，是挣钱。未来十年技术怎么发展，我也不知道。但换一个角度考虑。现在的主流技术如spring、net他们的发展都是迭代的。无论spring mvc还是boot核心都是IOC和DI，再核心就是OO编程。这样满足这个点就比较容易了，就是选择一个主力技术框架，随着这个框架进行迭代升级进行自己框架的升级就行了。例如现在前端用VUE，如果后来出现一个新的前端框架更好用，我们能够只修改前端就完成功能迭代就行了，但每次升级都要完美支持历史项目才行不然就没办法满足1.1的要求。
总结一下就是通过使用这个框架能够在保证质量的情况下快速的开发出产品，并且无论是产品还是框架都能够进行模块化的升级，升级完成后还不影响其他模块。
2、提供的基础功能
2、1：权限模块
含用户管理、子系统/模块/菜单/按钮配置、角色管理、角色权限四个核心功能。主要关注用户的操作权限即能打开那些页面、能看到那些按钮。这个模块除了要满足基础功能外，还要完成对单点登陆的支持，只要是使用这个开发框架开发的系统，对于同一客户，在任一系统登录后，一段时间内都不需要再进行登录操作。
另外还有一个重要功能就是能支持系统模块化，在介绍公司产品形态的时候提到公司会有不同产品线，每个产品线又有不同的附属产品，每个产品甚至附属产品会有不同的团队在开发维护。客户会对产品线及附属产品进行自定义组合式购买，所以产品的运行模式就会如下图所示：
通过账号登录进去以后，账号权限内的所有公司产品都会呈现出来，有时候根据需要可能还会对接外部系统，用户在使用不同的系统时可以做到无缝切换，甚至可能会要求不同系统、不同模块下的菜单出现在同一个模块下。
2.2、机构管理
这个模块主要是用来支持用户的数据权限，总体来说这个应该属于权限模块的一部分，但因为它比较重要，也比较特殊，所以单独拿出来进行设计，一般来说数据权限需要支持以下几种情况。
a：可见自己及下级：这个又可以和操作权限结合分为：可见及可操作、只能操作本级，下级不可操作。
b：只能看自己级别的数据。
c：全部的数据权限。
d：还有一种情况比较特殊就是一个账号同时拥有两个机构的权限，如兼任的情况，这种情况可以通过切换机构的形式实现。
2.3、系统监控模块
这个模块主要用来监控系统的日常运行，实施或者售后使用的比较多。一般大型的公司会将这个作为一个独立的系统来开发使用，如阿里的鹰眼系统。但作为一个应用系统的支持模块来说它应该能做到下面几个功能点。
支持自定义日志记录功能，业务开发人员通过遵守一定的规则，能够任意在业务系统中记录任何一个点的业务日志，日志除了记录基础的发生时间、调用模块外还需要记录当时的业务数据、异常数据。另外通过一个有序的序号可以将几个点的日志串成一串，这串日志能够完整的反应某个业务流程。
另外还需要做到日志的可视化查询管理功能。
2.4、其他辅助模块
字典：能够让开发人员自定义字典，如果有可能字典还是需要和权限系统结合，但这里实现起来比较复杂，且有其他形式解决，可以暂时不做。
系统配置：一些系统相对固定，但是有可能会产生变化的config项。
这篇文章提出了框架的具体要求，详细的设计方案请参考另一篇文章《开放框架的实现方案》