02 企业 EA -应用软件架构设计规范.docx

应用软件 架构设计 设计规范 4.2.1 定义主题域 对业务过程模型、业务能力模型、系统用例等作出分析，参照全局数据模型，定义数据主题域及概 念数据实体，主题域的数据实体应高度相关，每项业务能力至少包含一个数据主题域。 4.2.2 定义逻辑模型 结合业务需求，对概念模型数据进一步分解和细化，完成数据概念模型中未涉及的实体属性、主键 及约束的定义，进行数据概念模型中的多对多关系的转化，生成关系实体，手工转换数据概念模型中的 继承实体，并定义其关联关系。建议采用UML2.0“类图”定义数据逻辑模型。 4.2.3 定义主数据 在本系统及多个系统间共享的基础数据属于主数据，应参照主数据管理平台（SG-MDM）的主数据定 义，决定主数据的参照引用关系。 4.2.4 定义数据流向 基于业务流程（通常是1级或2级业务流程模型）、业务能力，定义数据从一个数据主题流向另一个 数据主题，包括外部与本系统的数据流向。确保每个外部数据实体至少包含在一个数据流定义。 应说明期间数据是如何创建和变化，建议采用如下方式： 在当今快速变化的商业环境中，企业必须以高度的敏捷性和灵活性来应对不断演变的市场需求。这要求企业应用软件架构设计不仅要高效、稳定，还要能够适应业务需求的变化。《企业EA - 应用软件架构设计规范》正是一份旨在指导企业如何设计出既符合当前需求又能适应未来变化的应用软件架构的文档。 规范强调了设计过程的一致性原则，这需要架构师在设计过程中确保软件架构与企业信息化或ERP总体架构保持一致。在数据架构方面，一致性意味着要对企业内部的数据主题域进行清晰定义。主题域应基于业务过程模型、业务能力模型和系统用例进行分析，结合全局数据模型，明确数据实体之间的高度相关性。每一个业务能力至少要包含一个数据主题域，这样才能保证业务流程中的数据流动和处理有着清晰的归属和管理。 在定义逻辑模型时，设计者需要进一步细化概念模型，对数据实体的属性、主键及约束进行明确的定义。对于概念模型中未涉及的多对多关系，需要通过生成关系实体来进行处理。此外，手工转换数据概念模型中的继承实体，并定义其关联关系。推荐使用UML2.0的“类图”作为定义数据逻辑模型的工具，以便更直观地展现数据实体间的关系。 主数据的管理在多个系统间共享基础数据时显得尤为重要。因此，定义主数据需要参照主数据管理平台（SG-MDM）的主数据定义，决定主数据的参照引用关系。这保证了数据在多个系统间的一致性和准确性，为业务流程提供稳定的数据支持。 在数据流向的定义上，企业需要基于业务流程模型和业务能力来确定数据如何从一个主题流向另一个主题。这包括了外部数据与系统内部数据之间的流动。每个外部数据实体至少应该包含在一个数据流定义中，以确保数据流的完整性和透明度。数据创建和变化的过程应当明确说明，通常建议使用业务流程—数据实体操作矩阵和数据流向图来描述。 除了数据架构外，技术架构也是企业应用软件架构设计的一个重要组成部分。技术选型需要基于技术可行性、运行维护可行性、进度可行性和经济可行性原则。架构师应遵循企业总体架构技术要求，并列出具体的技术选型列表。对于技术选型的偏差，应启动偏差流程并获得批准后才能执行。 应用架构的设计目标在于定义应用功能、应用划分和应用边界。应用功能的定义应通过关键用例或特性分析来完成，涵盖了交互功能、业务逻辑控制和数据维护。采用“鲁棒图”或类似的工具进行功能定义，可以更直观地展现应用的结构和功能。 这份规范为企业提供了一个结构化、灵活且高效的软件设计框架。它不仅支持企业的业务战略发展，还能确保软件架构与企业整体信息化战略相协调。通过遵循这些设计规范，企业能提高软件开发的效率，降低系统调整成本，增强系统的集成性和可扩展性。这将为企业在激烈的市场竞争中提供一个坚固的后盾，使得企业能够快速响应市场变化，保持竞争力。