苏ICP备112451047180号-6
投递平台功能分解与设计
上一章描述的需求分析工作已经确立了投递平台的工作方式，利用手机终端软件把邮政业务的电子化信息扩展到投递的末端，提高投递员投递效率和作业效率，扩展投递员的业务范围，通过数据信息的采集和分析，向管理层提供了准确、及时的经营分析报表及数据，进而实现增强河南省邮政业务的综合经营分析和管理决策的能力。本章将在需求分析的基础上，具体介绍投递平台的功能分解和软件架构设计过程。
表3-1 投递平台子功能需求与业务承担单位表
投递信息实时反馈：投递员在手机上查询到应投递的给据邮件信息，将邮件状态（妥投、再投、转退）实时反馈投递系统，业务人员根据利用收寄时或已有收件人手机号对再投、窗投、银企邮件短信通知。及时的提高了邮件投递效率和投递服务。除了反馈投递结果外，投递员在投递邮件时针对名址修改的单位和个人，实时更新有效的名址。这样缩减分拣、投递作业时间时限。投递员开始投递工作，手机客户端就开启GPS坐标上传，投递信息管理平台用地图的方式向管理者实时显示出投递员轨迹路线。
分销物流访销业务：投递员在手机上向村邮站人员显示邮政的畅销商品、最新商品、推荐商品的商品信息，然后选择订购商品的目录，选择村邮站名称、订购数量。这些订购信息实时上传到河南邮政商品管理系统，配送员可以有计划的进行商品配送、减轻配送成本和提高了配送质量。
目前，邮政提供的给据邮件投递服务，已经提供了互联网查询跟踪投递情况的功能，在收件、分包、转包的过程中，由于处理流程都在邮政系统内部，相关信息的录入相对及时，而在最后一公里，投递的过程中，投递结果的反馈实效性却落后于国内外同行先进水平。原因在于邮政投递员出班开始户外工作以后，就处于信息孤立状态，对于投递结果无法及时反馈。由于无法区分办公电话与个人电话，在投递过程中甚至无法根据电话联系收件人，对于投递现场找不到本人也没有单位收发室接收的情况，只能等待回到投递站后，才能尝试电话联系。这种方式降低了信件的一次妥投率，并延迟了投递结果的系统录入。
名址系统是邮政集团统建的一个标准地址库，它将邮政标准街道编号、单位名称、段道编号进行匹配关联，将各类命名方式的投递地址信息，转化为标准地址命名方式，并归属到邮政段道，是邮件分拣和投递工作的重要依据。
系统在使用过程中还要对名址信息进行不断的修正和维护，以适应街道更名、单位变更、段道划分变更所带来的名址信息过期的问题。同时旧地址信息依然需要保留，作为次要匹配依据，以保证用户填写旧地址信息依然能够进行匹配。具体工作都由工作在全省各个段道的投递员完成，每个段道的投递员都需要熟知所负责段道的大小单位，对常见的笔误、简称、旧地址等不规范的信息进行人工纠错。投递员的工作经验是邮政投递质量的重要保证，将这些宝贵经验收录到名址系统，必然会大大增强名址系统的匹配率，减少人工分拣工作量。
当前名址信息维护工作，由投递员在投递归班后整理新发现的名址变更信息，并将需要更新的名址信息报给投递站的信息录入员，由信息录入员进行统一录入。这种采集方式脱离了信息采集现场，并且增加了信息移交流程，使得整个过程不够实时、准确，并且投递员无法从系统中得到个人所维护的信息。因此不少投递员更倾向于所属段道名址信息记录在笔记本上，随身携带，一旦投递员流失，相关信息也会随之流失。
因此采用手持移动终端随时随地采集、查询信息是名址库维护的理想方式。投递员发现名址信息不准确的时候，只需要在移动终端实时录入相关信息，即可完成新名址信息的收录，无需等待归班后再进行信息移交。同时移动终端提供投递员所属段道名址信息的查询匹配功能，在功能上替代了投递员随身携带的笔记本，并且更加方便快捷。
县物流局对全县的终端进行分级，根据实际情况设定终端的所属段道并维护终端店主手机号码；由于物流系统中商品信息数据量太大，还需要县局管理人员定制本县允许投递员通过手机终端下订单的商品，设定个终端级别的价格和预付款优惠价格。
投递员每天出班前同步商品信息和本段道的终端信息；投递员到销售终端后，通过手机客户端选择终端类型（村邮站、三农网点、直营店、连锁超市）缩小选择范围，然后选择订货终端。
投递员选择终端订货商品，客户端软件提供模糊查询、分类查询、按照商品编号查询等多种方式定位商品；获取商品名称列表，点商品名称显示详情，详情包含，商品规格，商品单位，保质期，县局库存数量，根据订货的终端级别和是否预付确定商品价格显示价格；投递员输入订货数量，按钮“订单详情”，“继续选购”；继续选购，商品选择界面重新操作。
在订单详情中的每条明细后增加删除按钮；通过手机终端软件将订单信息实时发送到物流商品管理系统后台，后台将订单信息以短信的形式发送到向终端店主手机；订单分为四种状态：未配货、已配货、终端取消和县局取消；终端在订单尚未配货之前可取消订单；县局可在后台主动取消订单（交过预付款的订单不能取消），主动取消订单后，后台通过短信的形式通知终端店主；预付款的订单，投递员归班后到物流局上缴预付款，县局业务会计在系统中对缴款的预付款订单明细进行勾挑核实。
县局业务会计根据订单信息进行配货；在现有系统的现款销售和终端缴款中增加投递员缴款模块，实现投递员收款信息的录入；系统提供由投递员下订单投递员收款、投递员下订单县局直接收款和投递员下订单配送员收款等多种情况的销售额和收入报表，为日后县局计算投递员奖励提成提供数据基础。
访销业务的商品信息和终端信息是T+1日进行ETL数据同步，次日可以同步到手机终端上，而访销订单数据上传、订单信息查询、业绩查询时实时与主机通信。如果手机终端提交显示失败，而服务器端成功，再次提交时，系统根据订单的唯一性进行容错处理。
投递反馈业务的基础信息同步是实时通信，各种业务的反馈与签到的信息通信也是实时实现，网络结构图如图3-1所示。平台以投递反馈业务为基础搭建，由投递员手持终端、邮政各级业务管理客户端、省集中应用服务器和数据库服务器组成。在此架构基础上，邮政多个专业的业务可以逐步加载。并根据各地业务发展的特殊需求，进行灵活配置。
系统后台服务器计划采用F5负载均衡技术，多台服务器共同对外提供服务，随着业务量增长，可以方便的将更多服务器并入负载均衡从而完成性能扩展。
图3-1 投递平台网络结构图
这种分层方式是依据代码具体功能将其分类，自下而上，将数据访问、数据操作相关的代码打包成动态库接口提供给应用层；应用层通过访问数据访问层相关的接口对工程中相关逻辑处理的部分打包为动态库，并提供给表现层；表现层直接与用户打交道，接收用户提交信息，反馈用户请求的处理结果。JAVA的MVC，微软的Pet Shop标准分层案例，都是典型的分层方式，各种维度的分层方式可以在实际应用过程中可以根据工程的特点进行灵活运用，甚至交叉使用，以达到最合理的分层效果。
本系统基本思想在于将现在以及将实现的业务进行充分的分解。分解为应用逻辑、业务流程逻辑、数据访问逻辑三种不同层次的基本逻辑。通过这样的分解，使其中任何一层逻辑的修改都不会影响其它层，从而最大限度的降低系统内部的耦合性，提高系统适应变化的能力。
不同层的程序可以部署在不同的服务器上，根据服务器压力情况，灵活的分配和扩展服务器资源，在应用层和数据采集层着重分散数据传输压力，减少单一服务器，单一端口的数据吞吐量，在业务处理层着重分散服务器计算能力，通过负载均衡降低服务器CPU使用率，投递平台分层架构如图3-2所示：
图3-2 投递平台的分层架构图
应用层包含平台内应用和平台相关系统应用，平台本身提供投递信息管理、访销订单下单、投递员轨迹展示等应用，通过投递平台进行的访销操作，数据源来源于邮政商品管理系统，订单的后续处理、商品配送也是由商品管理系统完成。平台提供的名址维护功能服务于省函件局名址中心负责管理的名址维护系统，基础的投递反馈功能，邮件数据来源和反馈的目标都是集团公司投递系统。由此可见，投递平台是连接邮政各个专业现有系统的一座桥梁，在此平台上附加的多种应用，都可以灵活扩展邮政各个专业现有系统的数据来源，改变服务流程以获得更为便利的用户体验。
业务逻辑层由一些与业务过程无关的业务单元或应用组件构成，它们通过存取数据库或其它业务对象实现各自的业务逻辑。流程逻辑层的功能是管理这些业务流程，包括定义、控制业务单元间的数据流和控制流，以及将业务单元的操作映射到业务逻辑层的实际业务对象或应用组件。
将流程逻辑从应用中分离出来，再配以方便可供随时调用的WEB服务接口，即可以实现开放的、显式的、松耦合的流程，这种流程管理方案可以缩短设计周期并生产出高质量的产品，允许软件通过集合已存在的软件，组装生成新的应用，可以更快的创建灵活敏捷的应用系统。
数据采集层采用手工数据采集和GPS采集两种方式，手工采集是传统数据采集方式，包含数据抽取、数据下载导入、手工逐条录入等方式。由于平台关联多个业务系统，相关的基础数据需要通过系统间接口进行抽取，或者下载为固定格式进行导入，具体采用那种方式和那种数据交换格式，一般又第三方系统所能够提供的接口来决定。订单信息、投递反馈信息、名址信息的上送，由GPS采集的方式获得，以保证后台系统能够实时获取移动终端提交的请求。
1）支撑函件局的给据邮件投递反馈、名址信息维护、商函回执、形象期刊投递反馈业务，为函件局所属的各类需要对投递过程进行跟踪查询的邮件种类进行投递反馈服务，同时也为名址中心提供了名址维护的又一个渠道。主要由投递员操作。
2）支撑报刊发行局的报刊目录查询、党报党刊投递反馈和报刊收订业务，其中报刊收订业务预计在项目二期进行开发，一期首先的完成目录查询功能为报刊收订业务打下基础。
图3-3 软件架构图
3）支撑分销物流专业的移动访销业务发展，提供在线制单、订单查询、订单撤销功能，订单的后续处理由核心服务层完成。
4）数据下载功能，服务于所有业务，包含平台上已经加载的函件、报刊、物流服务，也可以服务于平台后续加载的业务，通过核心服务层的数据下载服务提供相关业务的基础数据下载功能。
5）系统管理功能，提供投递平台数据手工初始化、角色与权限的配置、业务报表查询统计的功能，主要操作者是各级业务管理人员，目前包含省市县三级业务操作员和定销局管理员。
核心服务层为应用层提供逻辑处理和数据访问的服务，包含数据下载服务、投递反馈服务、订单处理服务和报表服务，计划采用WEB服务的方式对应用层提供接口。数据下载服务根据外部系统所能提供的接口，将所需的业务数据定时同步到本地，并以统一的WEB服务的方式提供各类业务数据的下载更新服务。
投递反馈业务根据反馈邮件、报刊的种类，将移动终端上送的投递信息反馈到各自的业务处理系统；订单处理服务包含订单相关商品的调配服务，以及订单状态的实时调整和查询服务。报表服务提供各类业务的报表查询数据，通常采用实时和隔日两种方式，对于查询范围小，数据计算量小的报表可以提供数据的实时查询，对于查询范围大，数据计算量客观的报表则由日终程序在每日凌晨左右进行计算，隔日提供计算结果的查询功能，以降低系统的运算负荷。
函件专业需要的函件查询、各类函件投递反馈功能在应用层设计中有独立的模块，具体逻辑处理通过调用核心服务层的投递反馈服务模块来完成；报刊发行专业所需的投递反馈功能在逻辑上与函件投递反馈没有太大区别，仅仅是投递对象不同，因此报刊投递反馈共用核心服务层的投递反馈模块；分销物流专业的访销需求，在应用层有独立的访销订单下单、订单查询模块，在核心服务层有独立的订单处理模块供下单界面调用；
核心服务层的数据下载模块同时为三个专业提供数据下载服务，供给各项业务应用层查询调用，满足函件局应用层业务相关的函件基础信息下载，满足报刊发行局应用层业务的报刊目录下载，满足分销物流专业应用层所需的商品目录下载、销售终端信息下载。
核心服务层报表服务模块，主要为管理者提供实时的和非实时两种业务报表。对查询范围较小，主机运算量有限的报表，为应用层提供实时查询接口；对于查询范围广，占用主机资源明显的报表，则由报表服务避开业务高峰期，凌晨定时完成报表计算工作，为应用层提供隔日报表查询服务。报表服务不仅能够服务于现有的三个专业，也可以随着业务扩展，为平台加载的更多应用提供报表服务。
结合图3-3描述和第二章的2.3节业务需求分析，上述的对应关系见下表3-2所示。
表3-2 投递平台子功能需求与业务承担单位表
其中，数据库层存储各个专业业务开展所需的专用数据，同时也存储平台运行所需的公共数据，数据库设计将在下一章节进行介绍。
此阶段的工作主要由技术部门完成，具体设计工作由项目组架构设计人员完成，全体开发人员共同参与讨论，使每一位项目开发人员能够在项目的架构上达成共识。
上一章描述的需求分析工作已经确立了投递平台的工作方式，利用手机终端软件把邮政业务的电子化信息扩展到投递的末端，提高投递员投递效率和作业效率，扩展投递员的业务范围，通过数据信息的采集和分析，向管理层提供了准确、及时的经营分析报表及数据，进而实现增强河南省邮政业务的综合经营分析和管理决策的能力。本章将在需求分析的基础上，具体介绍投递平台的功能分解和软件架构设计过程。
3．1 系统功能分解
项目实施分两期进行，第一期先实现投递信息实时反馈、分销商品访销订购两大模块，业务需求方分别由报刊发行局、函件局、分销物流局承担，具体计划如表3-1所示：表3-1 投递平台子功能需求与业务承担单位表
| 功能名称 | 业务承担单位 | 子功能说明 | |
| 投递信息实时反馈 | 函件局 | 给据邮件、商函投递实时反馈流程需求 | |
| 形象期刊投递反馈流程需求 | |||
| 移动终端名址维护的操作步骤和内容需求 | |||
| 报刊发行局 | 报刊投递实时反馈流程需求 | ||
| 移动终端报刊征订操作步骤需求 | |||
| 投递员投递轨迹监控需求 | |||
| 分销物流访销业务 | 分销物流局 | 移动终端商品展示功能需求 | |
| 移动终端访销下单操作需求 | |||
| 河南邮政物流商品管理系统订单信息处理需求 |
分销物流访销业务：投递员在手机上向村邮站人员显示邮政的畅销商品、最新商品、推荐商品的商品信息，然后选择订购商品的目录，选择村邮站名称、订购数量。这些订购信息实时上传到河南邮政商品管理系统，配送员可以有计划的进行商品配送、减轻配送成本和提高了配送质量。
3．1．1 投递反馈功能
投递反馈即投递员完成当日投递后，将相关邮件的投递结果按照邮件类别分别反馈到对应的投递系统中，收件人和发件人就可以通过互联网查询、电话查询等的方式了解邮件的寄达的情况。目前，邮政提供的给据邮件投递服务，已经提供了互联网查询跟踪投递情况的功能，在收件、分包、转包的过程中，由于处理流程都在邮政系统内部，相关信息的录入相对及时，而在最后一公里，投递的过程中，投递结果的反馈实效性却落后于国内外同行先进水平。原因在于邮政投递员出班开始户外工作以后，就处于信息孤立状态，对于投递结果无法及时反馈。由于无法区分办公电话与个人电话，在投递过程中甚至无法根据电话联系收件人，对于投递现场找不到本人也没有单位收发室接收的情况，只能等待回到投递站后，才能尝试电话联系。这种方式降低了信件的一次妥投率，并延迟了投递结果的系统录入。
名址系统是邮政集团统建的一个标准地址库，它将邮政标准街道编号、单位名称、段道编号进行匹配关联，将各类命名方式的投递地址信息，转化为标准地址命名方式，并归属到邮政段道，是邮件分拣和投递工作的重要依据。
系统在使用过程中还要对名址信息进行不断的修正和维护，以适应街道更名、单位变更、段道划分变更所带来的名址信息过期的问题。同时旧地址信息依然需要保留，作为次要匹配依据，以保证用户填写旧地址信息依然能够进行匹配。具体工作都由工作在全省各个段道的投递员完成，每个段道的投递员都需要熟知所负责段道的大小单位，对常见的笔误、简称、旧地址等不规范的信息进行人工纠错。投递员的工作经验是邮政投递质量的重要保证，将这些宝贵经验收录到名址系统，必然会大大增强名址系统的匹配率，减少人工分拣工作量。
当前名址信息维护工作，由投递员在投递归班后整理新发现的名址变更信息，并将需要更新的名址信息报给投递站的信息录入员，由信息录入员进行统一录入。这种采集方式脱离了信息采集现场，并且增加了信息移交流程，使得整个过程不够实时、准确，并且投递员无法从系统中得到个人所维护的信息。因此不少投递员更倾向于所属段道名址信息记录在笔记本上，随身携带，一旦投递员流失，相关信息也会随之流失。
因此采用手持移动终端随时随地采集、查询信息是名址库维护的理想方式。投递员发现名址信息不准确的时候，只需要在移动终端实时录入相关信息，即可完成新名址信息的收录，无需等待归班后再进行信息移交。同时移动终端提供投递员所属段道名址信息的查询匹配功能，在功能上替代了投递员随身携带的笔记本，并且更加方便快捷。
3．1．2 分销物流访销业务功能
访销是指通过投递员主动走访商户、个人的形式进行物流商品销售的过程，这项业务充分利用了投递员熟悉当地零售商户以及需要批量购买物流商品的个人的特点，在日常投递工作的基础上，增加了商品销售的职能。现投递员使用手机终端完成分销物流商品订货、收预付款的功能。县物流局对全县的终端进行分级，根据实际情况设定终端的所属段道并维护终端店主手机号码；由于物流系统中商品信息数据量太大，还需要县局管理人员定制本县允许投递员通过手机终端下订单的商品，设定个终端级别的价格和预付款优惠价格。
投递员每天出班前同步商品信息和本段道的终端信息；投递员到销售终端后，通过手机客户端选择终端类型（村邮站、三农网点、直营店、连锁超市）缩小选择范围，然后选择订货终端。
投递员选择终端订货商品，客户端软件提供模糊查询、分类查询、按照商品编号查询等多种方式定位商品；获取商品名称列表，点商品名称显示详情，详情包含，商品规格，商品单位，保质期，县局库存数量，根据订货的终端级别和是否预付确定商品价格显示价格；投递员输入订货数量，按钮“订单详情”，“继续选购”；继续选购，商品选择界面重新操作。
在订单详情中的每条明细后增加删除按钮；通过手机终端软件将订单信息实时发送到物流商品管理系统后台，后台将订单信息以短信的形式发送到向终端店主手机；订单分为四种状态：未配货、已配货、终端取消和县局取消；终端在订单尚未配货之前可取消订单；县局可在后台主动取消订单（交过预付款的订单不能取消），主动取消订单后，后台通过短信的形式通知终端店主；预付款的订单，投递员归班后到物流局上缴预付款，县局业务会计在系统中对缴款的预付款订单明细进行勾挑核实。
县局业务会计根据订单信息进行配货；在现有系统的现款销售和终端缴款中增加投递员缴款模块，实现投递员收款信息的录入；系统提供由投递员下订单投递员收款、投递员下订单县局直接收款和投递员下订单配送员收款等多种情况的销售额和收入报表，为日后县局计算投递员奖励提成提供数据基础。
3．2 系统架构设计
架构设计要求构建以移动终端为基础的投递平台，以信息化手段优化原有的投递、访销、名址搜集工作流程，满足全省业务发展需求。3．2．1 网络结构
移动终端与服务器通信的网络，通过通信公司的虚拟专用网连接到省中心服务器，增强数据传输的速度和安全性，通信协议是采用.SOAP ，使用的标准是JSON轻量级的Web Service。[10]访销业务的商品信息和终端信息是T+1日进行ETL数据同步，次日可以同步到手机终端上，而访销订单数据上传、订单信息查询、业绩查询时实时与主机通信。如果手机终端提交显示失败，而服务器端成功，再次提交时，系统根据订单的唯一性进行容错处理。
投递反馈业务的基础信息同步是实时通信，各种业务的反馈与签到的信息通信也是实时实现，网络结构图如图3-1所示。平台以投递反馈业务为基础搭建，由投递员手持终端、邮政各级业务管理客户端、省集中应用服务器和数据库服务器组成。在此架构基础上，邮政多个专业的业务可以逐步加载。并根据各地业务发展的特殊需求，进行灵活配置。
系统后台服务器计划采用F5负载均衡技术，多台服务器共同对外提供服务，随着业务量增长，可以方便的将更多服务器并入负载均衡从而完成性能扩展。
图3-1 投递平台网络结构图
3．2．2 应用系统的分层架构
信息系统常用的分层方式主要将系统分为表现层、应用层和数据访问层，从而形成三层结构，便于用当前普遍流行的.NET或J2EE平台开发。这种分层方式是依据代码具体功能将其分类，自下而上，将数据访问、数据操作相关的代码打包成动态库接口提供给应用层；应用层通过访问数据访问层相关的接口对工程中相关逻辑处理的部分打包为动态库，并提供给表现层；表现层直接与用户打交道，接收用户提交信息，反馈用户请求的处理结果。JAVA的MVC，微软的Pet Shop标准分层案例，都是典型的分层方式，各种维度的分层方式可以在实际应用过程中可以根据工程的特点进行灵活运用，甚至交叉使用，以达到最合理的分层效果。
本系统基本思想在于将现在以及将实现的业务进行充分的分解。分解为应用逻辑、业务流程逻辑、数据访问逻辑三种不同层次的基本逻辑。通过这样的分解，使其中任何一层逻辑的修改都不会影响其它层，从而最大限度的降低系统内部的耦合性，提高系统适应变化的能力。
不同层的程序可以部署在不同的服务器上，根据服务器压力情况，灵活的分配和扩展服务器资源，在应用层和数据采集层着重分散数据传输压力，减少单一服务器，单一端口的数据吞吐量，在业务处理层着重分散服务器计算能力，通过负载均衡降低服务器CPU使用率，投递平台分层架构如图3-2所示：
图3-2 投递平台的分层架构图
应用层包含平台内应用和平台相关系统应用，平台本身提供投递信息管理、访销订单下单、投递员轨迹展示等应用，通过投递平台进行的访销操作，数据源来源于邮政商品管理系统，订单的后续处理、商品配送也是由商品管理系统完成。平台提供的名址维护功能服务于省函件局名址中心负责管理的名址维护系统，基础的投递反馈功能，邮件数据来源和反馈的目标都是集团公司投递系统。由此可见，投递平台是连接邮政各个专业现有系统的一座桥梁，在此平台上附加的多种应用，都可以灵活扩展邮政各个专业现有系统的数据来源，改变服务流程以获得更为便利的用户体验。
业务逻辑层由一些与业务过程无关的业务单元或应用组件构成，它们通过存取数据库或其它业务对象实现各自的业务逻辑。流程逻辑层的功能是管理这些业务流程，包括定义、控制业务单元间的数据流和控制流，以及将业务单元的操作映射到业务逻辑层的实际业务对象或应用组件。
将流程逻辑从应用中分离出来，再配以方便可供随时调用的WEB服务接口，即可以实现开放的、显式的、松耦合的流程，这种流程管理方案可以缩短设计周期并生产出高质量的产品，允许软件通过集合已存在的软件，组装生成新的应用，可以更快的创建灵活敏捷的应用系统。
数据采集层采用手工数据采集和GPS采集两种方式，手工采集是传统数据采集方式，包含数据抽取、数据下载导入、手工逐条录入等方式。由于平台关联多个业务系统，相关的基础数据需要通过系统间接口进行抽取，或者下载为固定格式进行导入，具体采用那种方式和那种数据交换格式，一般又第三方系统所能够提供的接口来决定。订单信息、投递反馈信息、名址信息的上送，由GPS采集的方式获得，以保证后台系统能够实时获取移动终端提交的请求。
3．3 软件架构的设计
软件架构是应用系统架构的具体实现根采用面向服务的方式进行分层，软件架构的分层的优势显而易见，降低了层与层之间的耦合性，例如更换数据库时，只需要重写数据访问层即可，业务逻辑层；同样的方法提供的接口可以被上一层程序反复调用，有效的提高了代码的复用性，降低了维护成本。在大型项目的部署过程中，分层的方式可以有效分散每一层的网络负载或者运算负载，将不同层级的程序部署在不同服务器上，根据实际运行情况配置各层的负载均衡，找出系统的性能瓶颈，就可以方便的针对性能弱点进行系统的扩容，无需进行软件修改，软件架构如图3-3所示：[4]3．3．1 软件架构各层级功能分配
应用层直接与终端用户打交道，是系统各级操作用户所能接触到的具体功能模块，对应系统架构设计中的展示层，但也包含部分简单的业务逻辑处理，具体内容有：1）支撑函件局的给据邮件投递反馈、名址信息维护、商函回执、形象期刊投递反馈业务，为函件局所属的各类需要对投递过程进行跟踪查询的邮件种类进行投递反馈服务，同时也为名址中心提供了名址维护的又一个渠道。主要由投递员操作。
2）支撑报刊发行局的报刊目录查询、党报党刊投递反馈和报刊收订业务，其中报刊收订业务预计在项目二期进行开发，一期首先的完成目录查询功能为报刊收订业务打下基础。
图3-3 软件架构图
3）支撑分销物流专业的移动访销业务发展，提供在线制单、订单查询、订单撤销功能，订单的后续处理由核心服务层完成。
4）数据下载功能，服务于所有业务，包含平台上已经加载的函件、报刊、物流服务，也可以服务于平台后续加载的业务，通过核心服务层的数据下载服务提供相关业务的基础数据下载功能。
5）系统管理功能，提供投递平台数据手工初始化、角色与权限的配置、业务报表查询统计的功能，主要操作者是各级业务管理人员，目前包含省市县三级业务操作员和定销局管理员。
核心服务层为应用层提供逻辑处理和数据访问的服务，包含数据下载服务、投递反馈服务、订单处理服务和报表服务，计划采用WEB服务的方式对应用层提供接口。数据下载服务根据外部系统所能提供的接口，将所需的业务数据定时同步到本地，并以统一的WEB服务的方式提供各类业务数据的下载更新服务。
投递反馈业务根据反馈邮件、报刊的种类，将移动终端上送的投递信息反馈到各自的业务处理系统；订单处理服务包含订单相关商品的调配服务，以及订单状态的实时调整和查询服务。报表服务提供各类业务的报表查询数据，通常采用实时和隔日两种方式，对于查询范围小，数据计算量小的报表可以提供数据的实时查询，对于查询范围大，数据计算量客观的报表则由日终程序在每日凌晨左右进行计算，隔日提供计算结果的查询功能，以降低系统的运算负荷。
3．3．2 软件架构与需求分析的对应关系
第二章的需求分析按照业务需求的提出单位进行分类描述，而软件架构则按照软件架构分层设计，在业务需求向软件架构设计的转化过程中，出现了维度不同的差异。本节将简要介绍需求分析中按照专业部门维度描述的业务需求，与软件架构设计图中分层描述的软件架构之间的对应关系。[1]函件专业需要的函件查询、各类函件投递反馈功能在应用层设计中有独立的模块，具体逻辑处理通过调用核心服务层的投递反馈服务模块来完成；报刊发行专业所需的投递反馈功能在逻辑上与函件投递反馈没有太大区别，仅仅是投递对象不同，因此报刊投递反馈共用核心服务层的投递反馈模块；分销物流专业的访销需求，在应用层有独立的访销订单下单、订单查询模块，在核心服务层有独立的订单处理模块供下单界面调用；
核心服务层的数据下载模块同时为三个专业提供数据下载服务，供给各项业务应用层查询调用，满足函件局应用层业务相关的函件基础信息下载，满足报刊发行局应用层业务的报刊目录下载，满足分销物流专业应用层所需的商品目录下载、销售终端信息下载。
核心服务层报表服务模块，主要为管理者提供实时的和非实时两种业务报表。对查询范围较小，主机运算量有限的报表，为应用层提供实时查询接口；对于查询范围广，占用主机资源明显的报表，则由报表服务避开业务高峰期，凌晨定时完成报表计算工作，为应用层提供隔日报表查询服务。报表服务不仅能够服务于现有的三个专业，也可以随着业务扩展，为平台加载的更多应用提供报表服务。
结合图3-3描述和第二章的2.3节业务需求分析，上述的对应关系见下表3-2所示。
表3-2 投递平台子功能需求与业务承担单位表
| 软件架构层级 | 各层级子模块 | 需求分析 |
| 应用层 | 给据邮件投递反馈、名址维护、商函回执、形象期刊 | 函件投递中的需求分析 |
| 期刊信息的需求分析 | ||
| 名址维护的需求分析 | ||
| 报刊目录查询、党报党刊投递反馈、报刊收订 | 报刊发行的需求分析 | |
| 分销物流在线制单、订单处理、订单查询 | 分校物流的需求分析 | |
| 系统管理、数据下载 | 服务于全部业务需求 | |
| 核心服务层 | 投递反馈服务 | 函件投递中的需求分析 |
| 名址维护的需求分析 | ||
| 报刊发行的需求分析 | ||
| 期刊信息的需求分析 | ||
| 访销订单处理服务 | 分校物流的需求分析 | |
| 数据下载和报表服务 | 服务于全部业务需求 | |
| 数据库层 | 系统数据管理、数据存储 | 服务于全部业务需求 |
3．4 本章小结
本章依据需求分析阶段从各个专业获取的需求，从技术角度对其进行功能分解，将来源于三个业务部门的需求归并为投递反馈和访销两个主要模块，并对其进行子功能的进一步分解；根据省内现有的网络资源情况，和系统的安全、性能要求完成了网络结构的设计和软件架构的设计。此阶段的工作主要由技术部门完成，具体设计工作由项目组架构设计人员完成，全体开发人员共同参与讨论，使每一位项目开发人员能够在项目的架构上达成共识。