what's the difference between service layer and domain model layer

Question 1

The Domain Model contains information and functionality related to what it means to be a User. It should map conceptually onto something that exists physically in the real world or a clearly defined concept in the problem space.

The Service contains information and functionality related to performing atomic units of work. It should map conceptually onto tasks that are performed on or by members of the Domain model. A single atomic task performed by clicking a button in the application generally involves many members of the Domain working together, unless you app is just a CRUD-y electronic filing cabinet.

Question 2

Entity: something that maps to some kind of entity (= object of interest) in the problem domain. In some cases (DDD) there are rich domain models where entities have methods that can manipulate the model's state. The more conservative approach is to make them anemic (no methods except getters and setters). Usually an Entity class ends up getting mapped to a database table.

BO: I'm guessing this is some kind of Data Transfer Object. Some people get very concerned about restricting access to entities to only a limited part of the application, and they like to copy data from entities into DTOs. So a service may receive an entity from a DAO, then copy that into a DTO and that DTO is what the service's caller would get back.

A Data Access Object provides a way to query or update data, it could have query methods that would return an entity or collection of entities. DAOs usually don't define database transactions, they let the service do that.

A Service is something that performs some task, for instance the different use cases usually don't break down cleanly along entity lines. Also services usually involve dependencies that entities try to avoid (because the domain model is about modeling state and changes to state, and the dependencies are about infrastructure). A service may have methods that implement use cases for some user, where each method is transactional.

Question 3

Maybe too high level of an overview, but here is how I've approached layering before, it is pretty much in line with your traditional N-tier architecture.

Web - interface between user's browser and your service layer, converts HTTP params into data your service layer would need.

--- Use Business Objects to communicate between these layers ---

Service - interface between your Web layer and your DAO layer, nothing specific to transmission protocols here, i.e. no HTTP requests/parameters, Business Objects in your case. All your business logic resides here. For example, if your web layer says "give permission 1 to user 1234", your service layer would convert permission one to READ and user 1234 to the UserEntity that backs it in the DB.

--- Use Entities to communicate between these layers ---

DAO - interface between your Service layer and the actual persistence mechanism, should be as dumb as possible, meaning if "purchase" object is expected to have a "user" object on it, the DAO should be given both, it should not have to deal with looking up the user for example.

Using this separation between layers makes it easy to unit test and maintain each layer independently of others. To elaborate on BO's, the biggest benefit of those if getting data from the front-end to the service layer encapsulated in a single object and it leaves looking up actual DB entries to the service layer. Hope it helps.