| Category | Service Design |
|---|
| Scope | Functional |
|---|
| References | None |
|---|
Design Case Study
Case 1: System A is a banking application which has been developed for ABC bank. Verifying credit limit for an account is one of the core business logic for credit card accounts. Whenever a transaction is being made against an account, the system should verify the current credit limit. The current credit limit is calculated by previous outstanding balance and paid amount for the billing period.
Case 2: System B is an online trading cloud application. It also enables overseas customers for doing trade, however the system should clearly indicate the overseas customers so that some financial benefits need to be reviwed by the accountant of the business.
Problem
Some applications are designed to persist some of the functional behaviors or the result of a behavior as attributes and other behaviors are worked or taken decision based on these attributes. This makes bad design of the system and after a while the system will act only as a transformer of data and sooner become domain incognizant. Also, keeping this practise will end up with more number of attributes (which is again treated as data) for a business data.
Validating and processing on the data are the fundamental behavior of applications. These core business logic on the data need to be consistently applied whenever the data is being consumed by one or more functionalities. In some cases, result of these core business logics are persisted as state in the application database table. This would lead the application complex for any upgrade in functionality especially applications those are developed and maintained by larger team. After a while, the application will become a dump-in and dump-out of data without any knowledge of the business.
Case 1: System A uses "IsCreditLimitCrossed" flag in the database table for credit limit verification before allowing a transaction. This flag is actually revisited by the same module after completion of every transactions. This makes the system unhealthy, in some cases unsafe when other functionalities are also operated based on this flag.
Case 2: System B has maintained a flag called "IsOverseasCustomer" based on the country entered by the customer and country for market he mentioned during the registration.
Forces
- Continuous functionality integration
- Make the system behavior driven and avoiding status flag driven decision
- Avoiding unnecessary piles of data for other data
Solution
Application should have their business decision or logic in the functional modules, not in the data. This can be achieved by creating core basic services for the entire application. This functionality will be one of the capability.
Case 1: System A should have "Check Credit Limit" core functionality as a basic service so that necessary functionalities can be implemented driven by this.
Case 2: System B shoould always do the checking by the country of customer and country for his trading.
When designing an application, the following practicses will help to keep away from this pattern:
- Whenever doing a data model, create a behavior attribute matrix for a data. This matrix should be maintained as part of functional design. Keeping the size of the matrix simple and doing a review during any functionality changes will help to keep away from this pattern.
- Honor and trust application data. In the given case study, trust the account balance, customer country and trading country.
Reference
This article is from my original series at http://www.udooz.net/article/6-patterns-for-enterprise-soa-using-wcf.html
