注：今天整理自己写过的关于企业架构和IT规划咨询方面的文章，对于企业架构规划方法给人最大的一个思考就是将其和SOA，和云计算架构思想的融合，并理清四大架构之间的协同和集成关系。

Related Articles

企业架构规划思想概述

企业架构（Enterprise Architecture EA）是从企业全局的角度审视与信息化相关的业务、信息、技术和应用间的相互作用关系以及这种关系对企业业务流程和功能的影响。从这个定义至少可以看到重要的两点，其一是业务、信息、技术和应用的融合；其二是EA包括了业务和IT两个重要的方面，是从全局考虑业务和IT的集成。企业架构是一个多视图的体系结构，它由企业的业务架构、信息架构、应用架构和技术基础架构共同构成。

业务和IT的融合

IT规划涉及到咨询方法论、流程管理和分析、信息架构、应用系统分析和设计、技术架构、项目管理和实施等众多方面。从企业战略到业务目标，从业务目标到IT目标，从IT目标到应用蓝图，从应用蓝图到分阶段实施落地，任何一个步骤的脱节将导致规划内容无法落地。再完美的规划和架构，如果脱离企业业务目标，都不能带来企业业务价值的提升。

IT规划之难，不在于IT本身，而在于流程；不在于技术本身，而在于业务。

对于IT规划，遵循的思路主要是：从业务到技术，从流程到IT，围绕价值链分析和优化的核心模型驱动。核心过程包括现状分析、差距分析、目标提出、蓝图规划、实施规划等几个关键步骤。现状分析包括业务现状和IT现状，根据企业战略提出业务目标和发展规划，分析现状和目标之间的差距提出和整理问题集（定义IT建设目标），根据差距和问题给出规划蓝图，根据目标和问题分解到的子目标和子问题以及蓝图规划内容，多维度评估和确定后续的实施规划，定义IT系统建设实施的优先级。这就是IT规划的一般逻辑。

从以上的描述可以看出，整个IT规划始终围绕业务和IT两条主线，业务包括了业务流程，业务数据，岗位组织和角色，业务管控体系；而IT包括了数据架构，应用架构体系，技术架构和平台，基础设施建设。业务驱动IT，端到端业务流程最终落地到应用系统的功能上，业务数据最终映射到数据模型并沉淀到数据库中。

随着各种思路的不断融合，IT规划核心指导思想应该转化为企业架构层面。企业架构的提出，主要是为了解决业务和IT“两层皮”的问题，企业架构的整个方法应该融入到整个IT规划思想中。此外，核心业务模型和业绩标准作为核心指导思想，虽然有裁剪，但是必须参考，如供应链SCOR模型，产品研发IPD方法论，项目管理PMBOK体系，战略和人力资源的平衡记分卡，CRM的4P和4C，财务域的核心模型等。针对不同行业可能又有不同行业的业务标准和模型，如电信行业的eTom模型等。

企业架构和SOA，云计算思想融合

与此同时，在前面基础上再融入云计算和SOA的核心思想，它将很好的解决我们多年前IT规划经验里的多个竖井式IT系统的集中化和协同化的问题。若现在规划仍走以前的老路是不妥当的。那么，今天规划重点在开始之初就应该考虑集中化和协同的问题，将SOA思想融入到IT规划当中。当今的信息化规划，要务必避免出现IT重复建设和信息孤岛，流程断点和业务无法协同的局面。

对于业务架构，其入手点是端到端的业务流程分析和流程分解，然后按照高内聚松耦合原则规划离散自治的业务组件。业务组件本身提供对外的粗粒度服务能力，这些服务能力能够更好地组合，组装或编排满足业务流程的需求。这恰恰就是SOA的核心思想，按此思想进行规划分析，顶层设计和建模，那么对于以后整个企业架构规划来说自然是基于SOA思想。不从流程分析入手的业务架构很难真正说它如何去匹配端到端的业务流程。

在业务架构的分析中，我们同样要随时考虑可复用的业务组件的抽取，可复用的业务功能的抽取，可复用的业务流程片段的抽取，复用的分析和抽取在业务建模阶段应当充分考虑，并不是遗留到应用架构和技术架构阶段。复用本身分业务和技术能力两方面，业务能力层面的复用和业务建模阶段相关。

对于数据架构，其核心不是数据分类和数据域的划分，而是从概念模型到逻辑模型到物理模型的数据建模和分析方法。在云和SOA思想指导下我们需要关注两个方面：一方面是核心主数据和共享数据，另一方面是数据集成和交换。这是建设企业整体共享数据中心的一个基础，存在共享的SID数据中心并提供可共享的数据服务能力本身就可以理解为PaaS平台中一个核心的内容。没有SID数据中心的分析和抽取，那么整个企业架构中的各个组件变成单纯的数据集成和交换，则谈不上共享能力集中化和服务能力云化。这个我们在规划中一定要注意这个问题。

数据架构本身是包括了业务和应用两个层面的内容。数据域和概念模型偏业务，而逻辑模型和物理模型偏应用。其次，为何要将数据架构和业务架构一起分析，核心原因是流程分析和业务架构中，最终的业务功能和活动本身承载了业务对象和数据，这是数据分析和识别的一个基础。数据本身不是凭空来的，而是随着流程和业务活动产生的。

理清以上内容后，我们需要在业务架构和数据架构基础上考虑服务架构，前面的业务和数据架构分析和规划，已基本清楚了具体涉及到的数据服务，业务服务和流程服务，这就可以规划出初步的服务架构和服务共享集成模式。在服务架构的规划中，涉及到服务的分层模型，高层的服务视图和服务目录集规划，服务和业务数据架构的映射关系等。

有了前面这些基础铺垫，在应用架构就相对比较容易了。

首先，应用架构的总体思路是“平台+应用”的架构模式。“平台”既包括IaaS层基础设施平台，也包括PaaS层平台。平台的核心是提供共享的资源和服务，对于IaaS层其重点是提供共享的资源能力，对于PaaS层其重点是提供共享的业务服务，数据服务，技术服务能力。共享本身有包括了两种实现方式，一种是集中化建设后直接能力开发，一种是将其它组件的能力集成进来统一发布出去，这两种模式都属于共享的范畴。

对于IaaS层主要实现虚拟化资源池、弹性计算和存储，而IaaS层之上的平台层规划包括了业务和技术两个方面的内容，因此可以将平台理解为包括了业务平台和技术平台。业务平台提供业务能力开放，技术平台提供技术能力开放。

业务平台和技术平台本身定位要搞清楚，业务平台本身可以是依托构建在技术平台上面的，但是应用本身又既可以访问业务平台，也可以访问技术平台。举例来说，一个ESB平台产品是纯技术平台层面的内容，但是ESB上提供和接入了各种业务服务能力，即变成一个业务平台；一个标准的技术架构和框架是纯技术平台，但是基于这个技术平台我们扩展了各种公有的业务组件和共性基础业务能力，那么这个平台可以上升为一个业务平台。

在实际的企业架构规划中，也可以直接规划为一个大平台，即这个平台既需要提供业务能力，也需要提供技术能力。同时对于提供的业务能力包括了业务协同能力，共享数据能力，共享业务组件能力；技术能力包括了底层资源池能力，技术组件能力等。

在理清平台+应用的思路后，另外一个重点就是理清SOA构建应用的思路，核心就是通过服务解耦业务和技术。平台层提供服务能力，应用需要基于平台层的服务能力去构建，流程需要基于服务的编排去考虑等。这是我们的目标，但是目标落地实施来说相当有难度，那么重点可以放在基本的组件化要求，共享的服务目录库创建。至少需要体现应用是调用了共享服务能力来构建的。

在SOA思想下，彻底打破业务系统的边界，将业务变成一个个独立的业务组件是一个很重要的目标。如果企业架构设计和规划中，还是按照传统的一个个纵向的业务系统去独立规划和建设，那么最终仍然是一个竖井式的烟囱应用。

对于IT基础设施架构和规划，TOGAF是放在技术架构里面来阐述，因此也可以将IaaS层规划放到技术架构里面来。将IaaS和PaaS纯技术平台的规划放到技术架构中考虑。

企业架构规划分析核心逻辑

在前面的分析中，IT规划所遵循的思路主要是：业务驱动IT，围绕价值链分析和优化的核心模型往前驱动。核心过程包括现状分析、差距分析、目标提出、蓝图规划、实施规划等几个关键。

在企业架构规划中，架构分析的入口点，我们认为合理的方式是从整体的端到端流程分析入手，细化到各业务域的端到端，经过不断的流程分解到3-4级流程，最终细化到最底层流程（如EPC流程，它是流程，本身也是业务功能）。另外的一个方式是直接从业务活动信息收集入手，如根据组织架构和岗位职责直接收集业务功能点。第一种方式既看到面又看到点，从上到下层层推进；而第二种方法则是容易只看到点，但无法贯彻整个企业端到端流程。当然，流程分析并不一定能够涵盖所有的业务功能点，因为有些业务功能本身便是最底层的EPC流程，往往并不是从高端的端到端流程分解而来.如用章管理是一个业务功能和EPC流程，但并不一定能够挂接到高端流程上面。这也是端到端流程分析要注意的点，高端流程分析和分解是建立全局思维，但是仍然要借助第二种方法收集完整的业务和活动。

流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离，进行数据层面的数据建模和分析。分析在流程各个阶段和活动中产生的业务实体之间的关联和依赖关系。业务域对应到数据域和数据分类，进一步可以分析到具体的概念模型或逻辑模型。流程分析偏业务操作和事件，而数据正是业务操作的对象。SOA中强调操作和数据解耦，则正好是分析的两个维度。

业务架构中的业务组件划分强调的是业务本身的高内聚和松耦合原则。对于任何一个业务域基本有两种类型，一种是数据驱动型，一种是工单任务型。如资源、资产等核心数据对象，业务操作层面重点是对数据对象实现全生命周期管理。因此业务组件划分基本遵循底层为基础数据支撑层，上层为生命周期管理层，覆盖该数据对象的核心生命周期阶段。这是业务组件划分的一个基本思路。

对于业务架构的构建，特别是我们对某个业务域并没有深入的理解前，最好的方式就是流程驱动分析，抽离数据进行数据建模，然后进行CRUD矩阵分析，分析数据和业务功能的关系。对底层的业务功能进行组合满足高内聚松耦合的原则，然后从底向上的对细粒度的业务功能进行组合，形成高内聚的业务组件。当然在整个过程中往往我们会参考业界标准的业务架构参考模型，如供应链的scor模型，电信行业的etom模型等。

业务架构完成后，将会过渡到应用架构，两者基本是对应的。其中较大的差别点在于业务架构只关注业务，业务本身分为功能性需求，非功能性需求。非功能性需要中包括了平台层面的支撑需求，即应用的集成支撑和数据的集成支撑，公共平台层功能等。另外还包括了纯技术层面的非功能性需求。对于前者需要体现到应用架构中我们往往会分为技术支撑平台和应用支撑平台，技术支撑平台包括了安全，管控等；而应用支撑包含了数据平台，集成平台和流程平台等。应用架构一般会分为支撑层，应用层和决策层。其中的应用层基本可以做到和业务架构一一映射。

服务架构需要考虑业务系统间的集成点。这个集成点的分析我们期望可以将端到端流程结合应用架构中的业务系统，CRUD矩阵分析形成跨业务系统的跨系统交互流程图。这种流程图已不是纯粹业务层面的流程图，而是做系统交互分析的跨系统交互流程图。所有的跨系统交互点则为流程驱动下的业务集成点。而CRUD矩阵分析则帮助我们分析出数据驱动的数据集成点。前者为业务服务为主，而后者即以数据服务为主。两者在分析完备后最终都体现到应用集成架构中。

业务中的平台级和非功能性需求转化到应用架构中的底层支撑层，对底层支撑层中的核心技术进行抽取，最终转化到一个完整的技术架构。技术架构和业务无关，它所提供的是底层技术支撑层能力。

技术架构逐步转化到公共的平台层，提供核心的资源池能力。业务组件本身转化为能力单元，业务组件由平台资源承载，提供业务服务能力。业务服务最终又可以通过灵活的配置形成完整的业务应用。因此我们所说的解耦不仅仅是业务组件间的横向解耦，还包括了业务组件到底层平台，业务组件到上层应用间的纵向解耦。

企业架构规划知识体系构图

在2010年在企业架构，IT规划和SOA方面有了比较多的积累，这些积累来源于项目实践。而我们说的积累一定是项目实践后的抽象总结，对于IT规划和架构知识库的整理是2010年的一个核心工作。对于企业架构中的核心内容流程架构，数据架构，应用架构，基础架构，包括底层的基础设施架构都进行了较系统的梳理，使IT规划和SOA规划的方法论根据完善。而对于SOA规划很多都需要依据IT规划和架构展开，结合SOA实施和治理的内容，完善SOA标准和规范体系。在技术方面，则进一步对规则引擎，CEP，EDA，MDM主数据管理等内容进行学习和总结；进一步梳理SOA，BI，云计算，MDM之间的关系和集成。

参考业界IT规划的参考模型和框架，结合IT规划方法论和实施经验，重新整理了IT规划知识体系。对于横轴主要考虑IT规划的方法论和步骤，具体包括了参考模型，调研阶段，差异分析和匹配，目标架构，实施策略和管控治理六个方面的内容；对于纵轴包括了IT基础设施，业务基础设施，业务流程，数据，技术体系，应用系统，集成架构七个方面的内容。

对于IT咨询的核心基础知识，重新做归纳的话应该包括企业信息化基础，项目管理，流程管理，软件工程这几个方面的基础内容。而其中流程和数据又是核心的核心。流程体现了动态分析的思路，数据体现了静态分析的思路。而分析工具和方法本身涉及内容更多，这些在标准的资料里面都能够找到，关键还是流程和数据，已经由两者提升和抽象后的维度分析。

再谈业务架构

要注意业务架构是一个完整的概念，是有多个架构文档，形式化的图形建模共同完成的。只要是企业内涉及到业务的方方面面，人，事，物，时间，环境等都可以在业务架构描述中找到详细的内容或者其它内容。业务架构不等同于流程架构，流程架构是业务架构的一个部分；业务架构不等同于业务建模，业务建模仅仅是形成业务架构的一种方法；采用形式化的方法清晰的描述清楚企业业务即业务架构要完成的事情。

业务架构的形式可以以价值链或端到端的流程分析为切入点，组织结构和岗位角色建模是业务架构的一个基础内容，在此基础上围绕流程和数据两条线相互交互融合而展开，流程涉及到子流程，业务活动和业务操作；数据涉及到数据域，数据主题和分类，具体数据的概念模型和逻辑模型等。或者可以简单地说为刚开始是基于价值链分析，端到端流程的高端流程建模；在流程分解到一定程度后进入到业务用例分析和建模，业务对象分析和建模。

在流程建模过程中，特别是到分解后的下级流程，仍然是推荐采用EPC事件流程链的方法进行建模。EPC流程图包含了流程活动，事件，岗位角色，业务对象等多个内容并形成一个整体。更加方面对企业内业务流程中的各个关联事物进行全面的理解。所以整个流程建模的思路可以是高端价值链-》传统的流程图-》EPC流程图。

在前面这些过程或活动中，可以形成大量的输出文档和目录清单，包括了流程清单，每个流程的详细活动描述清单（活动，输入，输出，业务对象，岗位角色），业务功能或活动清单，组织信息清单，岗位和角色信息清单，业务对象详细描述清单等。如果仅仅是端到端流程分析来输出，那么这个清单不完整，因为有些业务功能或活动不在端到端流程上面，比如一些业务部门的日常例行管理工作，监控工作，统计分析工作等。这也是业务架构不能单纯的从顶向下完成的原因，为了弥补这个问题，还需要的就是对于企业内的各个业务部门进行业务调研和访谈，了解各个业务部门的业务目标，各个业务岗位的业务职责和工作内容，进一步识别出不在端到端流程和流程分解节点上的内容。由顶向下+由底向上才可能形成一个完整的业务架构需要的内容。

如果仅仅是上述这些内容，那还不是一个完整的业务架构，在ARIS流程建模或TOGAF中都没有专门提到CBM组件化业务模型，这实际是基于SOA的思路做业务架构的一个很关键的内容。业务能力组件化和组件能力服务化。业务组件是企业内部一个高内聚的能够完成核心的一个业务价值的业务能力单元，这个业务组件将以业务服务的方式朝外部提供服务能力。因此各个业务组件之间本身就应该是高内聚，松耦合的。

一个业务组件可以是代表一个业务域，一个业务单元，一个紧耦合的多个业务流程或业务功能的集合，企业价值链或某个业务全生命周期的某一个阶段等。业务组件构成一个完整的业务架构模型，该业务架构模型本身也可以逐层展开和细化。业务架构本身分层，包括IBM的CBM模型的分法(决策，管理，执行层），也可以参考价值链的分层思路(支撑层，核心价值层，决策层）等，如上图示例。

在进行企业架构建模的时候，应该分为哪些大的业务组件，或者说哪些业务功能应该放在一个业务组件里面以保证组件之间能够高效协同是业务架构建模必须关注的问题。在业务架构建模的过程中，特别是对于目标业务架构完全可以参考企业所属于的行业的涉及到的标准模型进行重构和完善，如供应链的SCOR模型，电信行业的eTom模型等。我们在构造这个业务架构图的时候一直强调的就是高内聚松耦合的思路，符合业界的相关参考模型和标准，但是实际执行的时候究竟该遵循什么思路？

在这里一个可行的思路仍然是回归到矩阵分析，这里涉及到矩阵分析比较多，一个个的说明：

业务组件交互矩阵：在该矩阵上横向和竖向都是业务组件，在内容单元格里面是具体的业务交互接口点，通过这个交互矩阵分析是可以全局的看到当前的业务组件划分是否会导致大量的业务接口存在。并分析每个业务接口产生的原因，以进行组件的合并，业务组件中业务功能的转移等。(后续应用集成架构分析的输入)

数据和业务交互矩阵：在该矩阵图上，横向具体的业务组件和业务功能，纵向是具体的业务对象，在内部是具体的CRUD信息，也即是传统的CRUD矩阵分析。在该矩阵分析中的重点是，对于同一个业务对象，CUD操作尽量减少分离，而读操作则可以共享。以减少业务对象数据的多头管理和维护。将统一业务表单和数据的维护尽量控制在同一个业务组件中完成。减少数据间的交互和传递。

流程交互分析矩阵：在该矩阵上面横向是具体的流程信息，纵向是具体的流程活动信息，在这个矩阵图上可以看到同一个流程活动或流程片段往往存在于多个不同的流程。该分析的重要作用是对流程建模中可复用的流程片段或流程活动进行抽象和分析。(SOA服务建模时候需要)

功能业务组件分析矩阵：在该矩阵上横向是具体的业务组件或模块，纵向是具体的业务功能，在该交互分析上重点是分析具体的可复用的业务功能，以对可复用的业务功能进一步进行抽取，形成可复用的服务。(SOA服务建模时候需要)

本文作为TOGAF业务架构各个产出工件形成和交互关系的一个补充，具体TOGAF的业务架构建模很多仍然是停留在标准方法论基础上，而没有具体的操作性指南。反而是类似联邦企业架构FEA给出了一些可以更方便实践操作的方法和案例。

再谈数据架构

首先在TOGAF的ADM方法论中将数据架构部分的内容放在了信息系统架构-数据架构部分，这个方式是不合适的。前面一直强调了企业架构的两条重要线索，一个是流程，一个是数据，这两者都是既涉及到业务架构部分，也涉及到应用架构部分。在最终架构的分析和分解，业务建模到IT实现的转换过程中，自然就会过渡到应用架构部分的内容。

因此再次强调业务架构中也有数据架构部分的内容，只是业务架构中的数据架构的重点在数据域，高层的业务对象和概念模型，在业务架构的端到端流程分析和业务用例建模过程中自然会衍生出对应的业务数据对象和业务对象模型。

数据架构包括两个方面的内容，一个是静态部分的内容，一个是动态部分的内容。

对于静态部分的内容重点在于数据元模型，数据模型，包括主数据，共享动态数据和所有业务相关的业务对象数据的分析和建模。而动态部分的重点则是数据全生命周期的管控和治理。因此不能单纯地将数据架构理解为纯粹静态的数据模型。在业务架构中的数据模型分析重点是主数据和核心业务对象，而应用架构中的数据模型则进一步转换到逻辑模型和物理模型，直到最终的数据存储和分布。

数据分两个层面的生命周期，一个是单业务对象数据全生命周期，这个往往和流程建模中的单个工作流或审批流相关；一个是跨多个业务域数据对象的全生命周期，体现的是多个业务对象数据之间的转换和映射，这个往往是和端到端的业务流程BPM相关。在这里要注意的是，数据虽然是静态层面的内容，但是数据的生命周期或端到端的数据映射往往间接地反应了流程，这是很重要的一个内容。

数据建模的方法包括了面向结构的传统的ER模型分析方法，也包括了面向对象的对象类模型分析方法，两个方法都是可行的数据建模方法。只是传统的ER方法更容易实现向底层物理数据库模型的转换，而面向对象的类建模方法更加容易体现抽象和复用。特别是在企业架构建模中，面向对象和面向结构往往并不是严格区分的，很多时候都会出现两种方法混用的情况，但是重点是要区分每种方法或工具的重点以及解决的问题。

结合数据后相关的矩阵分析相当多，在业务架构阶段重点的矩阵分析是业务对象和业务流程，业务组件，业务功能间的类CRUD矩阵分析；而在应用架构阶段重点则会是逻辑或物理模型对象和具体的应用模块或应用功能间的矩阵分析。两者的思路基本类型，但是只是关注层面不同。前者的重点是主数据的识别和业务组件的分析，而后者的重点是应用功能模块的划分和模块间集成接口的初步分析。

对于数据集成分析根据前面的思路仍然应该分解为两个层面的内容，一个是业务层面的分析，一个是应用和IT实现层面的分析。前置的重点是理清业务流程或业务域之间的业务对象集成和交互，后者的重点是数据如何更好的共享或如果通过类似BI工具或ESB平台来实现数据的集成和交互。在TOGAF的信息系统架构-应用架构中特别要注意应该专门有一块内容来谈应用集成架构，解决的是业务系统和平台层技术组件间的技术集成，集成的实现方法，集成采用的工具技术等。

除了主数据之外，全局共享的动态数据分析仍然是数据模型分析的一个重点。或者说这个分析完成后基本可以找到整个企业端到端流程或某个业务域中的核心领域对象和领域模型。这个分析的重点是方便后续在实现层面进一步的构造通用共享的领域对象服务层，而不是纯粹的数据对象服务层。能够体现领域对象层延续前面讲的由业务-》应用-》集成的架构分析思路是相当重要的。

再谈应用架构

前面谈了业务架构和数据架构，接着谈下应用架构，对于应用架构的描述将参考TOGAF信息系统架构部分的内容，但是不完全相同，总体思路是围绕在IT架构层面来谈应用架构包括的内容。为了区分高层架构(包括多个应用的总体架构）和底层架构（针对单个业务系统的架构），前者采用企业架构中的应用架构这个词，后者采用系统架构这个词以进行区分。

首先说下应用架构中静态的部分，包括了应用功能架构和应用数据架构两个部分的内容，应用功能架构由业务架构中的业务组件架构转化过来，应用数据架构由业务架构中的业务对象数据架构或全局ER模型转化过来。中间会体现出映射关系。

对于应用功能架构可以比较明细的看到和业务架构之间的映射关系，但是要强调的是高层应用架构图中已经会明确地体现出了具体的业务系统，因此业务架构中的业务域业务组件和应用系统间往往不是一对一的关系，其中既存在合并也存在拆分，比如对于采购可能是独立的业务域或业务组件，但是在构建应用系统的时候可能是构建一个大的供应链系统；而财务是一个大的业务域，但是又可能拆分为报账，预算，成本管理等多个业务系统。这个一方面是结合企业实际情况，一方面仍然是考虑系统分解的颗粒度和耦合度。第二点应用架构和业务架构的不同体现在应用架构重点已经是在实现层面，需要实现业务架构朝IT架构层面的抽象和转化，最明细的就是底层可能会抽象相应的基础平台和技术平台，而上层或抽象相应的门户等，这些在业务架构中是绝对不会关心的内容。

业务架构阶段的数据架构重点是业务和领域对象，数据域的划分，主数据的分析和识别，重点是数据的概念模型。而到了应用架构则需要将业务对象转换为数据对象或具体的数据库表对象，应用架构的重点则已经是逻辑模型和物理模型。同时在应用架构阶段已经在分析数据对象和应用系统和应用功能之间的CRUD矩阵，以明确功能边界划分的合理性，以做到更好的系统划分和高内聚。

其次，在业务架构中有流程建模的动态建模部分，在业务架构中往往会从高端流程-》流程分解-》一直在具体的业务用例建模。而到了应用架构中要注意仍然存在动态建模部分，即业务用例-》系统用例-》用例实现，这个可以理解为应用架构中更加细化的动态建模，这个动态建模完全是实现层面的事情了，和本身应用系统的技术架构和分