Click here to Skip to main content
13,291,257 members (58,869 online)
Click here to Skip to main content
Add your own
alternative version


3 bookmarked
Posted 9 Dec 2009

WCF SOA Patterns: Anti-Pattern: Behavior Attributes

, 9 Dec 2009
Rate this:
Please Sign up or sign in to vote.
An enterprise SOA pattern using WCF explains the cons of behavior attribute
CategoryService Design


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.


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.


  • Continuous functionality integration
  • Make the system behavior driven and avoiding status flag driven decision
  • Avoiding unnecessary piles of data for other data


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. 


This article is from my original series at


This article, along with any associated source code and files, is licensed under The Creative Commons Attribution-ShareAlike 2.5 License


About the Author

M Sheik Uduman Ali
Architect Aditi
India India
Working as Architect for Aditi, Chennai, India.

My Website:

My Blog:

You may also be interested in...

Comments and Discussions

GeneralMy vote of 1 Pin
Marc Clifton11-Dec-09 5:21
protectorMarc Clifton11-Dec-09 5:21 
GeneralRe: My vote of 1 Pin
M Sheik Uduman Ali11-Dec-09 7:35
memberM Sheik Uduman Ali11-Dec-09 7:35 
Hi Marc,

Thanks for your feedback. Find my reply/opinion:

First, this pattern is not "WCF and behavior attribute". It is functional behavior attribute.

This pattern is mainly for functional design of a service. So, it did not cover any WCF related things.

For WCF or technical design area, I'll give more details.

Anyhow, I'll provide more details in parallel.

Keep your feedback and opinions.


M Sheik Uduman Ali

GeneralGood Article Pin
Paddy_pp11-Dec-09 3:29
memberPaddy_pp11-Dec-09 3:29 
GeneralRe: Good Article Pin
M Sheik Uduman Ali11-Dec-09 7:35
memberM Sheik Uduman Ali11-Dec-09 7:35 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.171207.1 | Last Updated 9 Dec 2009
Article Copyright 2009 by M Sheik Uduman Ali
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid