views:

36

answers:

1

Hello,

I have one module written on Java - web service module which accepts request process it(some business rules here), saves(modify or delete) values in db (using Hibernate) and then send status response). Is it reasonable to refactor that module so at the end there will be 2 modules - 1 is web service module and 2 - processing module where business rules applied and db processes made? and if yes then what is the good practices for information exchange between modules ? Thanks !

+2  A: 

Remember "KISS" - keep it simple; stupid.

It's more important to have a clean and maintanable code, focused on the domain model, rather than breaking it up based on technical considerations.

Yes; database storage is one aspect, yes, handling webservice calls is another, but its too easy to spend a lot of time to make a "clean" separation, with the only result that it takes longer to change things later. (As everone thats been working on an 14 layered "enterprise" application can tell you.)

Ideally, the "business logic" is the one module you write, and the webservice adaptation and the data storing just should work, "magically". As that is not the case, you obviously have to deal with that too, but its not the primary focus.

I strongly recommend that: the business rules = your datamodel. The webservice methods should be as thin as possible and expose the model as cleanly as possible.

This is a rather insighful article about the "business layer" http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx

Also remember that "layers" are abstract concepts, and its not a fundamental requirement that they are "physically" separated in diffent eclipse projects etc. Really, it's not.

KarlP