软件工程架构设计（二）

本次离线数据引入的业务需求到技术落地的过程是依旧按照下述流程进行设计：业务架构>>产品架构 >> 应用架构 >>技术架构，对于技术架构需要围绕复杂 >> 简单化>> 流程化 >> 自动化 >> 智能化的核心思想进行设计。

一、业务架构

1. 业务需求 & 业务规划

离线数据的引入需要围绕现状、核心目标、涉及用户进行深入讨论，将需要解决或留待优化的问题列表按照引入的流程进行细化。基于新系统涉及的业务方繁杂，需要与涉及的业务方进行脑暴式的讨论，反复多次讨论将需求明确下来，问题的解决方案可以都罗列出来，仔细讨论后可选择最合适的方案。

离线数据引入需求问题列表

2. 业务流程 & 功能模块

根据上述梳理出来的问题列表以及相应的可行方案后，梳理出业务流程。相对独立的步骤可作为业务模块抽取出来，并根据业务模块罗列功能组件。核心在于明确数据引入的需求需要由哪些功能支撑。

离线数据引入功能矩阵二、产品架构

1. 产品架构分层

根据业务功能矩阵的业务模块划分，按照流程顺序进行产品架构的分层。核心在于通过分层直观地展示产品功能模块的递进关系。

数据引入产品架构分层

2. 产品功能边界 & 信息流串联

根据产品功能的分层枚举，结合业务领域对产品功能进行业务聚合、划分，并对内部子模块进行职责确认。模块间数据的流转依赖于业务功能模块操作交互的关联性，因此在明确交互逻辑后，可以在此基础上将核心数据的流转逻辑梳理清楚。

数据引入产品功能模块边界、信息串联三、应用架构

1.应用架构分层

对产品架构映射到应用层面的模块进行划分，按照组织/业务架构水平划分，将同一业务范围的模块放在同一层级的原则。再按照功能模块垂直划分，将应用内部的业务逻辑差别较大时，遵循独立性原则进行切分并调研实现功能需要使用到的基础服务组件。

离线数据引入应用架构分层

2. 应用模块依赖

应用架构分层一定程度上标识了应用间的依赖关系，基于应用模块的独立性需围绕数据的流程交互将模块间的依赖梳理清楚。下述仅为核心流程的模块依赖展示，具体项目开发时需要明确每个功能的模块依赖关系以及依赖的具体接口，同时依据功能的模块依赖梳理可以印证应用架构是否合理。

离线数据引入服务模块依赖（核心流程）

四、数据架构

1. 识别核心领域 & 聚集根

分析核心功能流程涉及到的业务领域，业务领域依据功能独立性、可解耦的原则拆分成多个核心领域。核心领域根据其价值以及子领域是否有更多的功能职责（复用、语义独立性）确定是否继续拆分（拆成具体的表），子领域通过聚集根归属在同一核心领域下。领域驱动设计一定是针对复杂场景、流程的合适架构设计方式，对于简单的功能、只解决特定场景下单一问题的系统/功能，按贫血模型设计即可。

离线数据引入核心领域列表

2.确定依赖关系 &提取业务领域ER图

依据核心领域/子领域建立模型，根据功能流程的串联梳理模型间的依赖、关联关系。具体开发过程中需要将模型的所有字段罗列出来，并且关联关系需要到具体的字段上。

离线数据引入领域E-R模型五、技术架构

1. 调研选型

基于合适、简单、演化原则的战略思想进行技术调研以及功能设计。核心思想在于合适，包括简单、演化也不能极端化，不能不考虑必要的扩展工程应用，要遵循合适的原则。对于规则引擎的选定，首先需要统计现有业务方的所有清洗逻辑，再根据分类归属选择合适的规则引擎。

文件行去重规则

文件行拆分规则

文件行合并处理

文件列合并规则

离线数据引入技术选型调研

2.系统详细设计

2.1 技术逻辑架构：数据引入清洗应用工程模块划分

基于后续法律法规可能更加严格，不允许数据出域的情况下，需要考虑将核心清洗模块以及不同的算法模型能力集成到SDK中（SDK遵循最小范围设计逻辑），方便业务方快速、便捷使用。详细的功能设计依旧需要考虑异常、幂等、事务、高可用、高并发等设计原则（详细思路可参考上一篇文章）。

数据引入清洗项目工程模块

2.2详细功能流程设计

可使用swagger组件展示接口详情，方便联调实时感知接口变化。在进入提测阶段时，需要对接口文档做整理归档，可为后续接手人员提供详细的资料。使用流程图/时序图/泳道图(适合多应用交互流程)对功能设计细节进行梳理，具体使用那种作图方式，可根据流程复杂性与个人喜好选择，只要能把流程说明清楚即可，甚至可以文字描述步骤（不建议，不够直观）。2.2.1清洗SDK行清洗流程，可依托于流程编排+上下文思想实现（详情见流程编排）

行数据清洗流程六、总结思考

（编辑：海南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!