An Innovative Application Architecture

This diagram reflects the way I tend to design a typical multi-tier architecture for transactional and operational type of thin or rich client applications.

It takes some innovative approach to go a few steps beyond three tier architecture. A few popular design patterns are still being used here such as MVC, Service Façade, Domain Model, and DTO. However the differences will make this architecture much more flexible and modular by achieving higher degree of de-coupling.

I have always advocated that one of the most critical tasks for any architects in a project is to set the appropriate boundaries among the different software pieces. From vertical perspective, we can set boundaries from function, class, package, components, services, subsystems and etc. As the boundaries go wider, the higher circle will encapsulate the lower circles. From horizontal perspective, the most popular practice among IT shops is to set the boundaries using projects, which is what this architecture tries to address and avoid.

Here is what I like to point out further:

1. The diagram takes a holistic view to package code within a business segment (Life Insurance, for instance) in side a company, not each individual project view. So there are no project names in the packages.

2. The boundaries among the packages are set using four most critical packages: business domains, business rules, business processes and data services. This is an innovative way to achieve de-coupling and modularity.

3. The Service Façade package serves as the glue like a chassis to a car to tie everything else together. In the integration type of project, this will be different, which I will address later.

4. Further more, only the Service Façade package can access to the Data Service package, NOT any other packages. The data that Business Process and Business Rule packages need will be fed by Service Façade package. This is the cleanest solution to achieve the goal that Business Processes and Business Rules are self-contained, therefore, can be easily re-used, re-deployed, and extended – another innovation here.

5. Another unusual aspect of this architecture is that the Data Service package can call Business Rule package. One of the reasons is that sometimes Data Service needs business rules to form the WHERE clause of SQL statements.

6. The data that these packages needs will be carried by the Data Transfer Object (DTO design pattern), which in turn contains one or collections of Business Domain objects.