Monday, April 27, 2009

Domain driven design in SOA application stack

Typical application design stack consists of the following
  • User Interface Controllers / Integration Layer / Process Layer
  • High Level Services Layer (Facades, Composite Services, etc)
  • Low Level Services Layer
  • Application Persistence Layer (custom DAOs or ORM framework)
  • Database Server

The domain layer cuts across all the above layers, domain objects are passed across interfaces spanning the layers
Cross cutting concerns like security and transactionality are ideally applied at the high level services layer

Ideally, where should the business logic related to an application reside?

The domain driven design camp seems to be perfectly convinced it should reside in the domain classes. They even go on to critisize applications that do not have business logic in the domain classes. Such a domain model which does not contain business logic but only contains data members and getters/ setters is often called an anaemic domain model.

The service driven design camp seems to think the best place for the business logic to reside is in the services, especially, the low level services. One argument in there favour stems from increasing usage of ORM frameworks like hibernate and JPA, which require persistent classes getting mapped to relational tables.In such cases, having a light domain model that can easily be recreated again and again from a tunable underlying database, seems to be advantageous

One of the reasons why domain driven camp, seems to want business logic in domain objects is that often in earlier frameworks like EJB 1.x and 2.x, the service layer had a coupling to technology, but with POJO based frameworks like Spring, EJB 3.1 etc, whether business logic resides in the service layer or the domain layer it is very much easily reusable due to it being in POJOs

The more important principle that is getting obscured in this domain-driven and service-driven business logic debate is that the design "needs to be able to capture business requirements, in appropriately designed Object Oriented abstractions". When going down the path of service based business logic, there is much more danger of falling into the procedural trap and designing business logic in terms of sequence of linearly executing steps. Low level service layer should have OO abstractions that deal with domain specific concepts, entities and operations


Business logic can reside in domain layer and alternatively in the service layer as well. But special care needs to be taken in design for either case to ensure that business logic gets modelled keeping sound object oriented principles and best practices in mind.

Tuesday, April 14, 2009

Cloud Computing - relevance to enterprise applications

Some considerations for moving applications to the cloud:
  • Different applications in the enterprise have different scalability and load requirements
  • From a ROI perspective cloud based computing offers huge cost advantage only to applications which exhibit characteristics of extremely variable loads.
  • Specifically, applications for which the difference between peak load and average load or difference between average load and minimum load is very large, offer best ROI, when considered for cloud computing.
  • With cloud computing, pay-as-you-use economics, you don’t end up incurring huge up-front capital costs, nor do you have to buy hardware and software capacities that have to contend with rare peak loads say holiday season/year-end processing peaks
  • Also cloud computing is suitable for applications with requirements of extreme scalability
  • Cloud computing applications should be ready to contend with less than perfect reliability, say 99.5 % reliability, which may not be an option in some mission critical applications


  • Not every enterprise application should be considered for being moved to the external cloud. For some applications, good old virtualization, within the realms of the organization, should give great enough value. This type of infrastructure is refered to by some vendors as internal cloud
  • New or existing enterprise applications can be architected for cloud computing depending on the application's suitability
  • Cloud computing can be used very effectively to complement existing intranet based enterprise applications

For a more graphical explanation please view the slide share presentation hosted on linked-in Cloud computing relevance to enterprise applications