Domain Objects and Their Variants
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):
- 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.
- Domain Object == Business Object.
They are entity representitives in business layer, which shoud be understood by non-programming people, such as business analysts.
- Business Object should have both data and behaviour.
Anemic Domain Object are those business objects only have data without behaviour.
- 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.
- 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.
- 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:
- 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.
- 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:
- 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)
- 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.
- 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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)