在这里想谈下对于一个原来没有接触过的新行业的新业务系统切入的方法，当然谈这点的时候首先是需要已有有一定的IT行业其它业务系统的工作经验，包括业务和技术双方面的积累，那么在这种情况下如何快速的切入一个新的业务系统，就需要注意相关的方式和方法方面的问题。

粗粒度的全局了解

接触一个全新的业务系统，首先要搞清楚这个业务系统主要是支撑什么样的业务？而对于支撑的业务本身又有两个核心内容，即核心的业务流程是如何的？核心的业务对象模型是如何的？在这个了解清楚后可以继续了解这个业务系统大致会有哪些核心的业务功能模块，业务模块之间的相互关系是如何的？已经如何衔接的。

有时候了解到这个层面可能还不够，你还需要了解这个业务系统可能是支撑端到端业务流程或共享业务数据的一部分，那么还需要了解到这个业务系统或支撑的业务在端到端流程中所处的位置，该业务系统和上游业务和下游业务的关系，相互间的协同和接口。

业务系统支撑了什么样的业务，存储了哪些核心业务对象和数据，这是对一个业务系统最基础的全局理解。

动态了解-流程模型

在对业务系统有了一个全局的理解后，需要开始进一步考虑流程模型方面的内容。注意在这里指的流程模型不是指工作流或人工审批流模型，而是指业务流程模型。或者说了解业务系统本身在分析设计中所涉及到的业务建模方面的内容。

业务建模或业务流程模型的了解需要解决的问题是，一个业务系统为何会存在这些业务模块，这些业务模块之间是如何进行协同来支撑业务流程的。任何业务模块都会有输入和输出，了解清楚业务模块的输入输出后就能够比较清楚业务模块之间是如何串接和集成来支撑上层的核心业务的。

如果一个业务系统按SOA思想来建设，你可能会看到有哪些上层的核心业务模块，核心的领域服务层和底层的数据模型层，核心的业务模块本身是如何调用核心领域服务来进行协同和衔接的。只有清楚了业务流程才可能理解清楚业务模块之间的协同和集成关系，否则你看到的是孤立的业务模块，业务模块和业务流程之间出现断点而无法真正想清楚业务模块间如何协同来支撑业务的。

如果一个业务系统本身是流程型的业务系统，这些流程又大量是审批流为主，那么即使审批流定义再复杂，整个业务系统本身也是简单的，因为不存在上面所说的大量业务模块间协同情况。

静态了解-数据模型

对于一个业务系统的复杂往往体现在两个方面，一个方面是本身业务模块间的协同和交互复杂，一个是底层的数据模型和关系复杂。在解决了第一个层面的动态分析问题后，就需要开始考虑第二个层面的数据模型了解层面的问题。

任何业务流程，模块间动态的协同最终都将持久化到数据库中，成为数据库中的数据表和数据表之间的关联依赖关系，映射关系。业务系统前面谈到过或者是以流程为中心的业务系统，或者是以数据为中心的业务系统，对于数据为核心的业务系统必须理解底层的数据模型。这种数据模型的理解首先是要理解元模型结构，这种结构不是简单的单个数据对象，而是多个数据对象之间的关联关系，映射关系，层次关系等。正是由于数据之间有这些关系，而形成了一个复杂的数据网络。

对于数据模型的理解基本可以分为如下几种，一种是单对象的结构，包括主从，层次等各种结构；然后才是对象和对象之间的关联依赖结构，如一对多，多对多结构等。对于较为复杂的业务系统，你可能还会看到为了保证底层数据模型的可扩展性和灵活性，往往在数据模型层会根据面向对象的思路做进一步的抽象，那么在这种情况下还必须等将OO的对象模型和面向结构的数据库模型共同来参考理解，以分析和了解清楚最终数据存储的方式，数据存储后最终呈现的方式。

动静结合-关键业务分析

个人理解，对于新切入一个新的业务系统，如果能够理解到这一步，基本就可以对一个业务系统有一个比较全面的理解和认识。首先是了解业务流程和模块间协同，然后是了解数据模型和数据间关系，最后则是真正的根据核心业务来进一步理解在流程协同过程中最终数据的落地存储。由动态的业务流程驱动的最终静态数据的存储落地和关系的建立。只有这样流程和数据的分析最终才会融合为一个整体。

对于关键业务的分析你会看到，对于这些关键业务需要理解清楚究竟涉及到哪些模块的协同，在模块的协同过程中最终会产生哪些核心的数据，或者说会更改哪些核心数据的状态或数据间的关系。真正你需要关注的往往不是单个数据对象中某些数据熟悉的变更和修改，而更多的是关注核心业务流程驱动下，数据对象状态的修改，数据对象间关联关系的修改，数据间映射模型的调整等。

对于一个完整的业务系统，按道理只要有基本的数据对象维护功能即可，但是要真正能够支撑业务，你会看到数据对象中的关键属性，关键依赖关系的变更，最终都是由上层的业务模块和流程来支撑的，那么你就必须要能够真正的理解所有的核心业务流程最终对底层数据模型造成的影响。

如何了解熟悉业务