电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: 敏捷思维架构设计中的方法学(9) 分层 -2 [打印本页]

作者: look_w 时间: 2018-4-16 21:57 标题: 敏捷思维架构设计中的方法学(9) 分层 -2

业务层的设计比较简单，暂时只是把它实现为一组的业务类。类似的，表示层的设计也没有做更多的处理。表示层的类是继承自资源层的。这是一种处理的方法，当然，也可以是使用关系，这和具体的实现环境和设计人员的偏好都有关系，并不是唯一的做法。在对软件的大致架构有了一个初步了解之后，我们需要进一步挖掘需求，来细化我们的设计。在前面的设计中，我们对业务层的设计过于粗糙了。在我们的应用中，还存在一个旧系统，这个系统中实现了应用规则，从应用的角度来看，这些规则目前仍然在使用，但新的系统中会加入新的规则。在新系统启用后，旧的系统中的规则处理仍然需要发挥它的作用，因此不能够简单的把所有的规则转移到新系统中。（有时候我们是为了节省成本而不在新系统中实现旧系统的逻辑）。我们第二步的架构设计的细化过程中将会加入对新的要求的支持。
在细化业务层的过程中，我们仍然使用层技术。这时候，我们把原先的业务层划分为两个子层。对于大多数的企业应用来说，业务层往往是最复杂的。企业对象之间存在着错综复杂的联系，企业的流程则需要用到这些看似独立的企业对象。我们希望在业务层中引入新的机制，来达到组织业务类的目的。业务层的组织需要依赖于具体的应用环境，金融行业的应用和制造行业的应用就有着巨大的差距。这里，我们从一般性的设计思考的角度出发来看待我们的设计：

首先，我们看到，业务层被重新组织为两个层次。增加层次的主要考虑是设计的重用性。从我们前面对层的认识，我们知道。较高的层次可以重用较低的层次。因此，我们把业务层中的一部分类归入较低的层次，以供较高的层次使用。降低类层次的主要思路是分解行为、识别共同行为、抽取共性。
在Martin Fowler的分析模式中提供了一种将操作层和知识层分离的处理方法：

Action、Accountability、Party属于较高层次的操作层（Operational Layer），这一层次的特点是针对于特定的应用。但是观察Accountability和Party，有很多相似的职责。也就是说，我们对于知识的处理并不合适。因此，Martin Fowler提出了新的层次――属于较低层次的知识层（Knowledge Layer）。操作层中可重用的知识被整理到知识层。从而实现对操作层的共性抽取。注意到虽然图中的层次（Level）的概念和层（Layer）有所差别，但是思路是基本一致的。
另一种分层方法是利用继承：

该图中也是来自于分析模式一书。不同的部门有着差异点和共性，将共性提取到父类中是继承的基本概念。这时候我们可以把父类看作是较低的层次，而把子类看作是较高的层次。对于一组层次结构很深的类来说，也可以从某一个水平线上分离层次。
最后一种方法需要分解并抽象对象的行为。C++的STL中为不同的数据类型和不同的容器实现了Iterator的功能。它的实现是典型的降低层次的行为。我们不考虑它对不同数据类型的支持，因为它使用了比较独特的模板（Template）技术，只考虑它对不同的容器的实现。首先是对共性的分析，不论是数组（Array）还是向量（Vector），要执行遍历操作，都需要知道三个条件：容器的起始点、容器的长度、匹配值。这就是一种抽象。通过这种方式，就可以统一不同容器的接口。
以上我们讨论了细分层次的好处和实现策略。下面我们回到前例中，继续讨论层中的各个部件。
业务实体指的是企业中的一些单独的对象。例如订单、客户、供应商等。由于业务实体可以被很多的业务流程（业务会话）所使用，因此我们把业务实体放在业务实体层中。企业中的业务实体大多是需要持久性的。因此在我们的设计中，业务实体将持久性的职责委托给下一个层次中的持久性包，而不是直接调用数据库方法。另一种常用的方法是使用继承――业务实体继承自持久类。EJB中的Entity Bean就是典型的业务实体，它可以支持自动的持久性机制。
在我们的系统中，规则是一个尴尬的存在。部分的规则处于旧系统中，并使用旧系统的持久性机制。而新系统中有需要支持新的规则。对于上层的用户来说，并不需要知道新旧系统的规则。如果我们在使用规则时做一个新旧规则的判断并调用不同的系统函数，那就显得太傻了。我们的设计对上层而言应该是透明的。
所以我们总共设计了三个包来实现规则的处理。包装器包装了旧系统中的规则，这样做处于几点考虑：首先，旧系统是面向过程的，因此我们需要用包装器将函数（或过程）封装到类中。其次，对旧系统的使用需要额外的程序（或平台服务）的支持，因此需要单独的类来处理。最后，我们可以使用Adapter模式[GOF 94]将新旧系统不同的接口给统一起来，以使他们能够一起工作。新的规则类实现了新的规则，较好的做法是定义一个虚协议，具体的表现形式可以是虚基类或接口。然后由其子类实现虚协议。再结合前面介绍的把旧规则的接口转换为新的接口的方法，就能够统一规则接口。从图中我们看到，业务实体需要使用规则，通过统一的接口，业务实体就能够透明的使用新旧两种规则。
在定义了规则和标准的规则接口之后，上一层的规则控制器就可以通过调用规则，来实现不同规则组合。因此这个规则控制器就类似于应用规则。在业务交易处理中需要调用规则控制器来实现部分的功能。
请注意，这里讨论的思路虽然非常的简单、清晰，但是现实中的处理却没有这么容易。因为为新旧规则制定统一的接口实在是太难了。要能够使接口在未来也相对的稳定更是难上加难。而在应用已经部署之后，对已发布的接口的任何一个小改动都意味着很高的成本。在这个问题上，并没有什么好的策略，经验是最重要的。在实际中的一个比较实用的方法是为接口增加一些额外的参数。即便可能这个参数当前并没有使用到，但是如果为了有可能使用的话，那还是加上吧。举个例子，对于商业应用软件而言，数据库，或者说是关系数据库一定是不可缺少的部分。大量的操作都需要和数据库结合起来，因此，可以考虑在方法中加入一个数据库连接字符串的参数。虽然这对于很多方法而言是没什么必要的，但是为将来的实践提供了一个可扩展的空间。国内的某个知名的ERP软件的设计就采用了这种思路。

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)