系统服务化构建-项目整体框架
本篇文章旨在讨论如何组织通用型项目代码结构，以PHP YII2框架为例做说明，设计思想与语言本身无关。
以下是本文的大纲
业务服务型项目系统定位 基础功能组件 业务功能组件 基础功能组件与业务模块组件异同 宿主工程 模块之间调用关系
业务服务型项目系统定位
业务服务型项目，包括业务对外SOA API接口，微服务接口，业务中台服务，业务服务中间件，不包括通用的官网类似的MVC项目，CMS系统。
采用自顶而下，分而治之的思想，业务服务型项目主要包括基础功能组件，业务功能组件，公共方法类库，宿主工程四大部分
基础功能组件
基础功能组件由具体的基础功能模块构建而成，基础功能组件应该满足以下几个条件
1 功能与实际业务无关。属于系统底层框架或者代码模块
2 代码结构稳定，改动频率小，如果改动需要经过多人审核，review。
以上两点是衡量某项功能是否属于基础功能模块的基本标准。我们常见的可以纳入基础功能范围的有 短信服务，移动端推送功能服务，文件存储服务，固定的基础服务，Excel Word文件导出等
业务功能组件
业务功能组件由具体的业务模块构建而成，为满足产品或市场人员的需求为主。业务功能模块满足以下几个特定
1 功能灵活多变，同时兼顾解耦特定
2各个业务模块之间约定功能边界。
单方向调用，避免蜘蛛网式的嵌套调用
3 通过接口或者本地RPC保持与基本功能组件层次化的调用
业务功能组件跟着产品线，由业务决定，常见的业务功能组件如用户信息组件，账户组件，支付中心，应用注册中心等。模块的定义，组件的边界决定于业务模型，需求定义，市场时机等多种因素。
基础功能组件与业务模块组件异同
1 解耦，稳定，可用
软件模块的基本要求必不可少。
2系统中的所处的层析清晰，不可混用。
3 满足功能的维度不同，前者更倾向于稳定，可用，后者更倾向于灵活，实用，解决实际问题。
前者在设计时更多考虑技术架构，后者更多考虑业务架构。注意是【更多】。技术架构以软件技术，软件工程理论为核心，业务架构更多依靠产品线，业务线的补充叠加实现。
4都会涉及到数据层访问，缓存
公共方法类库
公共方法类库是一些零散的代码，未纳入基础功能模块的代码模块。未纳入基础模块的原因包括不符合基础模块的规范，比如以下原因
1 同时兼顾基础模块和业务功能，耦合性较强，短期版本交付周期内无法解决。
2临时性的第三方组件，功能及稳定性待验证
3 不符合命名空间合作类库约束
常用的公共方法库包括 数据类型转化，对象类型转换，日期自定义函数等。
公共方法类型在系统中位置没有严格的约束，一般在业务组件中使用较广
宿主工程
宿主工程在系统中位于最上层，起到调用业务模块的左右。宿主工程在部署后直接暴露出来被消费者使用， 如网站，服务接口，或者控制台可执行程序。
以下部分以改造后的YII2框架为例来示例以上各个层次
backend就是宿主工程，如果以网站的形式公开服务，部署时的网站配置文件的根目录则指向backend的web目录下
source就是公共类库包括未纳入基础功能组件的代码块和一些公用的业务模型model
注：以上借助于框架特性，以YII2 Module的形式来组织代码，Module的具体使用案例及生成规则不在此文章中讨论。
业务模块如何调用基础模块
1保持命名空间use 的正确性
2宿主工程或者业务模块的配置文件引入被调用模块的Module配置项 如
3 以模块的方式调用
在宿主工程的主配置文件下，我们引入模块的配置。UserService，SecurityService，AdminService是模块名称。
'modules'=>[ 'user'=>[ 'class'=>'appcomponents\modules\user\UserService', ], 'security'=>[ 'class'=>'infrastructure\modules\security\SecurityService', ], 'admin'=>[ 'class'=>'appcomponents\modules\admin\AdminService', ], ],
项目整体框架是后续系统维护和扩展的基础，根据代码实现的功能进行对应位置的划分，这里的位置特指基础设施或者业务实现。代码层次清晰，代码对应得功能职责就会清晰明确。
文章中对 结构的各个部分给出 了职责说明，略显简单，后边会有文章深入介绍，敬请期待。