I'm quite confused about Object Oriented Domain level design in an EJB context and where exactly to put Business Logic. I'd really love to hear some feedback as this problem really drives me crazy. Maybe someone else has got this right, or at least a happy medium.

In a nutshell we tend to do the following layering which I believe is relatively typical in EJB layering (although some may use different persistence frameworks etc):

1/ Use cases are reflected in Component level SLSBs(Stateless Session Beans). Transaction attributes are set at this level.
This is our service layer where Workflow type business logic occurs.
2/ DAOs with Hibernate implementations. (We also have Entity Beans floating around but that's another story)
3/ Bean classes/DTOs link 1 and 2 above together as well as being exposed over applicable Remote interfaces of SLSBs

Basically, in our domain model we have DAOs and Bean/DTO classes, where the DAOs take DTOs/Beans as parameters and return values. Almost all business logic happens in the SLSBs service layer.

I find the above approach really encourages poor procedural style programming.
The problem is :
Where do we put domain level business logic ? :
- If we put it into the DAOs it means we are polluting our data access with persistence logic.
- If we put it in the DTO/Bean classes this may not be good for Remote calls (or does this really matter, should we just pass domain classes over Remote interfaces ?, ie. How does domain business logic code affect serialization?)
- We could introduce domain level POJO facades, it would seem that this would produce an explosion of classes. Eg. For a "Product" domain concept we might then have the following :
- "Product" SLSB at the service layer (or some other facade with "Product" use cases.
- "Product" POJO Facade with domain level business logic
- "Product" Bean/DTO
- "Product" DAO
- Potentially "Product" hibernate Entity type bean classes.
.....That's just too much to manage !!

Now, I originally come from a C procedural programming background which was pseudo Object Oriented.What we used to do is have a module file with functions that operated on C data structs.
- Then I did C++ for some years and we used to encapsulate business logic with member data in domain classes in a classical Object Oriented manner. DB code was not clearly seperated which obviously had its share of problems, but it seems more OO-like than what I do now with J2EE/EJB.
- The Bean/DTO Classes in J2EE seem akin to what C Structs are, - not much better anyway.
- SLSB methods are akin to the C functions which operated on the C structs.
It seems to me like we have gone back in time.

Can anybody shed some light on the above problem? I read M. Fowler's articles on Anemic Domain Classes but it seems to me that domain level business logic would pollute J2EE layering ?