I read "Domain Object Dependency Injection with Spring" the other day. Actually, what interested me were those comments about the concepts and patterns around "Domain Object". I had been always confused about those buzzwords related to Domain Object: Domain Object, Business Object, DTO, POJO, Anemic Domain Object, Active Record Pattern.

After some research, I found several points critical to help understand those concepts (at least for myself):

1. Among those concepts, POJO is not that relevant.
   It's a general principal applied to all enterprise beans (service beans, dao beans, etc.) not to be framework-specifc, though framework-specific annotations are commonly used in 'POJO' these days.
2. Domain Object == Business Object.
   They are entity representitives in business layer, which shoud be understood by non-programming people, such as business analysts.
3. Business Object should have both data and behaviour.
   Anemic Domain Object are those business objects only have data without behaviour.
4. Data Transfer Object (DTO) is a concept within data access layer.
   DTOs are often used in conjunction with DAOs to represent data retrieved from a DB.
5. DTOs and Domain Objects can be designed to use the same class, even represented by the same object for the same entity. Personally, I think Domain Objects refer to the combination of DTO and Business Objects for plenty of cases.
6. Active Record Pattern:
   Domain objects have rich behaviour, for example, inject DAO into domain objects to make it has CRUD ability.

Understanding the above concepts is just half way, I would like to going further for things behind these domain object variants:

On the one hand, people like Martin Fowler thinks domain object should have data and behaviour, which is consistent with OOD. Anemic Domain Object is anti-pattern, which in effect causes 'procedure script' style thick service layer. On the other hand, anemic domain objects are still popular. For myself, the following two facts explain the phenomenon:

1. Active Record Pattern is really painful.
   I don't like the idea of putting DAO into Domain Object at all. And the clear multi-layer design, makes coding more intuitive and very easy to maintain.
2. Encapsulating behaviour into business object doesn't mean removing service layer at all.
   Just don't put all behaviour into service layer, this layer should be as thin as possible.

What I learned:

1. I will put behaviour only relevant to the individual entity into domain object, for example: validation, calculation, maybe CRUD (I still prefer having separate DAO to fufill the tasks, don't like any huge object)
2. Service layer should serve as a gateway to all above layer, which means any business atomic operation should find its place in service layer. Then, transaction can be managed in one layer.
3. Behaviour involves different entities regardless same type of entity or different types may go into service layer.

This is my personal opinion based on what I understand so far. Any comments or critisim are welcome.

PS. This is my first post:) Wish it good luck, and Merry Christmas to everyone.

More to say:

I've read the "Domain Driven Design" refcardz after writing this article, found out some similar points were already mentioned there, though DDD covers broad aspects. I think my article exposes some facts or problems of this topic, which would help people obtain deep insides via further reading. Actually, I am planning to read some DDD book as the second session after current looking up.