Your application typically consists of a variety of functionality – user interface components, business logic components including domain assets, business rules, and services, backend assets such as legacy components, packaged systems etc. If you tie your assets too specific to an application it will severely inhibit reuse. Application agnostic logic should be built as reusable assets. If they aren’t, plan to refactor so they are reusable.
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.
: 
: 
: 
: 
:
Posted by vijaynarayanan 
