Key Best Practice: Separation of concerns - the age old best practice!!!

Here I thought that reiterating the principles of separation of concerns would provide a great rrefresher.


It is my contention that architecturally it is a good idea to keep the persistence layer and the business logic layer separated just as it is to keep the presenation layer and the business logic layer separated. Especially, in the age of SOA this make a great deal of sense as it enables each layer to change independantly to enhance the overall agility and robustness of the solution and to increase the responsiveness to the business needs. Here I expound on the reasons for the separation of the persistence layer from that of the business logic layer.

A) Keeping the business logic from being comingled in the same objects that hold persistable fields (that are tied to the persistence store layout or database schema) is important as this separation of the persistence fields from the business logic allows the application/ component to deal with the changes to the database schema more efficiently. The corrolary is also true in that persistence related objects/entities are insulated from the changes to the business logic.

B) The separation of the business behavior from the persistence layer may have an added advantage of allowing the implementation and testing of the business behavior to remain independant of the implementation and testing of the persistence behavior.

C) In addition, these persistence related domain entities could become simple state encapsulation entities (DTOs) and could become the sole constructs that are traded/ exchanged between the persistence layer and the business logic layer

D) These state encapsulation entities (DTOs) could also be shared as parameters between components and/or applications and could be transformed into XML long as they all belong to the same business domain.


Your feedback is appreciated.

surekha -