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

Conclusion:

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.