Business-layer vs. model-layer

[vshankar]

This discussion is related to something I have been after for some while. A while back I searched many groups but couldn't find anything.

I think it would be great to come up with a default package structure that is a bit of a recommended practices for what types of classes go where and what they should do, something in the order of a maven standard directory layout but for packages. I have pulled down various sample code from different projects and tried to come up with something from that. Clearly there may be different "templates" for small versus large projects, diff reqts etc. but i'd find it very useful. For example:


NB: [namespace] = (e.g. com.company.project.[subproject])

NB: This is just an example and i'm def Not saying this is correct. Just wondering if anyone knows of something like this or has an interest in constructing one.

NB: All packages contain interfaces. If separate dirs for implementations, then subdirectory of 'impl'. If not separate dir interfaces + impls directly in package.

• [namespace].service = service classes which includes stateless services, managers, etc. ideally not static so that they can be easily be stubbed.
  Service classes may contain collections/caches to be able to track the model objects upon which they are working, but if so they should be thread safe if in a multi-threaded env (more and more common these days)
• [namespace].model = stateful domain classes. "managed"/operated upon by the service classes. often not beans but if so must be prototype and instantiation managed
• [namespace].dao = db abstraction. Here I'd like to detail suggestions - like for non-ORM recommended SimpleJdbcTemplate, declarative txn mgmt, etc...), for ORM.. blah blah. typically injected into services.

presentation, etc......

NOTE: I use 'service' generically to indicate stateless classes that provide a service and likely take return a result or potentially act upon the object passed in. To me this includes 'Services' and 'Managers' and things like 'Calculators' or anything that fits that description of acting upon objects. I generally use 'Manager' when the class is proactively managing rather than just providing a service. Further, if it acts upon the object rather than returning the "answer" the caller is after (the approach mockists apparently prefer from martin fowler's article http://martinfowler.com/articles/mocksArentStubs.html) , I generally call these Managers rather than Service but that's just a rule I've developed.

ALSO.. I watched a video on youtube a few months back from Rod Johnson where he talked about moving more of the business logic out of the services and into the domain objects [at least from my memory] because this is where you can easily get code reuse. This makes sense to me because often the domain/model is the comment component and the services are often application specific and therefore not as likely to be reusable. Having said that I have yet to really utilize this in practice. Ideally we would define in which package(s) the business logic should go, as well as common "rules" or troubles (e.g. try to avoid state here or synchronise it for thread safety or these typically are injected or get injected into others, etc. )

Other things that would be interesting to include is ibatis, and where bus logic goes here.


hopefully this already exists and someone can point me to it!

[Krutarth_Mehta]

I am intersted to understand, How this is possible to keep Business layer (Presenatation layer+Business logic layer) and persistence layer apart of each other so that I can make changes to Business layer/ Persistence layer w/o large effect to each other..Can we add any mediation layer to do this..

[alsdias]

I prefer thinking about MVC pattern:

"Model-view-controller (MVC) is a software architecture pattern that separates the representation of information from the user's interaction with it.[1][2]
The model consists of application data, business rules, logic, and functions.
..."
http://en.wikipedia.org/wiki/Model–view–controller


So the "model layer" comes to the following package structure, defining two tiers:
+--model
+-- business
+-- persistence

[Shiv_S]

Business Layer can contain business service classes which implement well-defined business interfaces. Eg: taking the standard ATM usecase, we can design a ATMService which has service api's like deposit(), withdraw() etc.. (I did not put the input params as I just quoted it for example)
These business layer classes will know to work on business domain objects. So in the above example, we can say deposit() knows to work on a Given account and for a given input Money instrument (say Cheque or Cash).

The domain objects need not necessarily be the Persistence layer objects, in the sense, for normalization sake our DB model or ORM objects might be a little different from the Domain object, as the ORM objects mostly map directly to table strcutures. The persistence layer will know how to create the Domain Object from the ORM objects or if there is no ORM, it will have the logic of building this object from various result-sets. It will also know how to extract data from domain objects and save to DB using ORM or plain JDBC, whatever the project tech stack is.

The business layer does not need to have the detailed logic of persisting the domain data encapsulated in the Domain objects.
All it needs to care about is the business logic. In the business logic implementation if there is a step to persist data, it will just call the persistence layer class (which probably will be coded to an interface). The business logic does not need to know how to persist.

This way we can draw a clear line between the two layers and using Spring dependency injection techniques can keep the dependencies between these layers configurable.

In the context of your question, I perceive the model layer as Persistence layer (not to be confused with the Domain Objects of the business layer).
Domain Objects also sometimes act as Data Transfer Objects or Value Objects to carry business data between layers.