Business tier assets could be a combination of objects and services. Your SOA efforts need to be brought into the picture here so you can leverage existing services for fulfilling application functionality. Enterprise data can be decoupled from your application either via a data access layer or a data services layer or a combination of both. Business rules can be encapsulated using Classes via the Strategy pattern or via a declarative rules engine. Either way you should ensure that most of your rules are standalone units of logic that taken a bunch of inputs and return a result. That way they are not specific to a single application. External system integrations should be encapsulated as well including connectivity, data transformations, target specific data values, and error handling. Equally important is handling exceptions in a consistent way across your application.

The idea is to reduce coupling between application specific logic and application agnostic ones. This will help you reuse technology assets in new and unexpected ways! This in fact is a foundational idea of Software Product Lines.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

If you have a set of business rules that are complex in nature determining decisions in your business process flow, it is better to encapsulate the into a separate component. If you have a rules engine in your SOA you can place these rules here and expose the rule as a decision service. If your implementation environment doesn’t have a rules engine, you can encapsulate rules as objects so they are isolated from the rest of the process orchestration logic. Why? Two immediate benefits: your rules can be changed independent of the process flow and your rules can be reused across multiple business process orchestrations.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :