WCF SOA 模式： 反模式： 行为属性

类别	服务设计
范围	函数式
参考文献	无

 

设计案例研究

案例 1：系统 A 是一个为 ABC 银行开发的银行业务应用程序。验证账户的信用额度是信用卡账户的核心业务逻辑之一。每当对账户进行交易时，系统都应验证当前的信用额度。当前的信用额度是根据上一结算期的未清余额和已付金额计算的。

案例 2：系统 B 是一个在线交易云应用程序。它还允许海外客户进行交易，但系统应清楚地标明海外客户，以便业务会计师需要审查一些财务福利。

问题

一些应用程序被设计为将某些功能行为或行为结果作为属性持久化，而其他行为则基于这些属性进行操作或做出决策。这导致了系统的不良设计，并且过了一段时间后，系统将仅充当数据的转换器，并且很快变得与领域无关。此外，保持这种做法将导致业务数据拥有更多数量的属性（这又被视为数据）。

验证和处理数据是应用程序的基本行为。这些关于数据的核心业务逻辑需要在每次一个或多个功能使用数据时一致地应用。在某些情况下，这些核心业务逻辑的结果作为状态保存在应用程序数据库表中。这会导致应用程序的功能升级变得复杂，尤其是那些由大型团队开发和维护的应用程序。过了一段时间后，应用程序将成为数据的倾倒和转储，而对业务一无所知。

案例 1：系统 A 在数据库表中使用“IsCreditLimitCrossed”标志来验证信用额度，然后再允许交易。在每次交易完成后，同一模块实际上都会重新检查此标志。这使得系统不健康，在某些情况下，当其他功能也基于此标志运行时，则是不安全的。

案例 2：系统 B 维护了一个名为“IsOverseasCustomer”的标志，该标志基于客户输入的国家/地区及其在注册期间提到的市场国家/地区。

力量

• 持续的功能集成
• 使系统行为驱动并避免状态标志驱动的决策
• 避免为其他数据堆积不必要的数据

解决方案

应用程序应在其功能模块中做出业务决策或逻辑，而不是在数据中。这可以通过为整个应用程序创建核心基本服务来实现。此功能将是其中一种能力。

案例 1：系统 A 应具有“检查信用额度”核心功能作为基本服务，以便可以由该功能驱动实施必要的功能。
案例 2：系统 B 应始终通过客户的国家/地区及其交易国家/地区进行检查。

在设计应用程序时，以下做法将有助于避免此模式

• 每当进行数据模型时，为数据创建一个行为属性矩阵。此矩阵应作为功能设计的一部分进行维护。保持矩阵的大小简单并在任何功能更改期间进行审查将有助于避免此模式。
• 尊重并信任应用程序数据。在给定的案例研究中，信任账户余额、客户国家/地区和交易国家/地区。

参考

本文摘自我发表在http://www.udooz.net/article/6-patterns-for-enterprise-soa-using-wcf.html 的原创系列。