Are there any best-practices or guidelines for naming conventions for the business layer in a n-tier architecture?

We are thinking of going with an n-tier architecture for a project that we are going to start. I just wanted to get an idea of naming conventions. I have read a couple of books and done some research on the net but I am still struggling to find an appropriate name for objects that do your basic CRUD. One book used the suffix logic. So if were dealing with products the business layer had an object that was called ProductLogic that did you get, update etc etc. I am not a big fan of that naming conventions.

Another resource suggested using the suffix Manager. So we would use ProductManager. I am not a fan of that one because at no point does the name really suggest what it does. It seems a bit ambiguous.

I am trying to keep the responsibilities of my classes nice and separate. So we have the Data Access Objects, which just do the data acc开发者_如何学JAVAess. We also have validators in a separate classes. The "Manager" co-ordinates the validation and the data access.

Are they any sort of naming convention when it comes to business logic layer objects?

---

The closest that I use is the suffix DTO for data transfer objects. The interesting ones in the business layer are named after what they are for, no suffixes/prefixes. We're using NHibernate, so those objects don't have any particular methods or properties in common beyond ID fields.