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

Question

for example, I have a user table, to be layer-ing, I create such POJOs:

UserEntity.java
UserDao.java
UserBO.java (business object, domain model?)
UserService.java (for service layer)

what's the difference between UserBO.java and UserService.java? why we seperate it to two objects?

Hellraiser

Business objects can simply contain primitive state (Strings, booleans, and numbers). Service classes perform actions on those objects. – Sixfooter

Generally speaking, business objects are nouns and the service methods are verbs. Service methods usually implement some specific process or step of a process that involves operations on one or more business objects. – Bloodthirsty

Here is a very good article that I found helpful.infoq.com/articles/ddd-in-practice – Bryce

See also #3689164 – Vivisection

See also #2295945 – Vivisection

Answer 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.

Emcee

Incidentally USER is kind of an awkward example, since unless what you're implementing is like a SAML engine or something, User records are really more in the system meta data realm than actual parts of the Domain..... – Emcee

Answer 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.

Burdett

Answer 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.

Gulden