http://separation-of-concerns.blogspot.com/ Bino B. has posted 2 posts at DZone. View Full User Profile

Business Logic in Domain Objects?

05.28.2010
| 21918 views |
  • submit to reddit

One of the design principles of any enterprise application which I found difficult to make up my mind about is Anemic domain models + Service Objects Vs. Fully featured domain objects.

Most of my business application layer consists of many Service Objects (DAOs, Session Beans, BOs, Delegates, Facades etc) AND many POJO domain objects. Here the domain objects are nothing but data holders. There is no business logic in it. Arguably, this is an application of "separation of concerns", where business and/or data access logic is separated from data holders (in other words, Transfer Objects or Value Objects). In my opinion, this also improves the testability of the code.

Whereas, there is a counter argument from another side (mostly the proponents of Domain- Driven Development (DDD)) that separating domain objects from its operations is nothing but going back to procedural style of programming. I don't know if I necessarily agree with that argument. Frameworks like Hibernate (even JPA) allows us to embed custom SQL's inside the domain model. In my mind that is a 'mixing' of concerns.

Also, imagine a method called sell() inside a 'Book' object. Does a book know how to sell it? Should it know? Also, Book has an existence without a sell() functionality. In cases like this, I prefer the business logic to be separated in to respective Service Classes which results in methods like BookServiceImpl.sell(book) and BookServiceImpl.calculatePrice(book) rather than Book.sell() and Book.calculatePrice().

This is not to totally dismiss the other argument. If we are developing software for a rapidly changing business domain, from a maintainability perspective, DDD approach may sound attractive. For example, when the way company sell books change , the place it requires the code change is most likely the Book.sell() method; where as, if we are to change the service method, it might affect various other sub-systems in which the service methods are re-used. But when Book object requires another domain object (e.g: 'CreditCard' object) to do its selling, things become complicated. Yes, we can inject CreditCard object into Book object, but effectively we are introducing a level of coupling and reducing testability.

 

Published at DZone with permission of its author, Bino B. Manjasseril.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jose Maria Arranz replied on Mon, 2010/05/31 - 2:21am in response to: Stephane Vaucher

Maybe you are talking about this class.

I don't understand your example, I was talking about the typical data model and the kind actions to be executed in this data model:

- Load/Save as XML

- Load/Save in some kind of DB

- Show in some kind of view technology

- Business behavior spanning several objects of several classes of the data model at the same time.

- Remote data access/transfer

...

For instance you are not going to find any SWT code in MethodDeclaration and if you find it ... bad!!

 

Jakub Holý replied on Mon, 2010/05/31 - 7:15am

Both the SOA-style architecture with anemic objects and DDD architecture have their pros and cons and there are cases when one is more suitable then the other, none is the "absolute winner". Adam Bien has written very good articles introducing both of them in the context of Java EE 5/6 - see Lean Service-Oriented Architectures and  Objects- or Domain-Driven Design.

Of course a Book wouldn't sell itself, as already suggested by some commentators, this is a cross-object responsability that should be put into an "orchestrating object".

Stephane Vaucher replied on Mon, 2010/05/31 - 7:48am in response to: Jose Maria Arranz

My comment was that the class is not a container for data; it offers services beyond data coherence. The services you mention are outside the scope of an AST representation of code and should be designed as such. That is SoC.

Jose Maria Arranz replied on Mon, 2010/05/31 - 9:16am in response to: Jakub Holý

Domain-Driven Design.

I don't buy this article, service objects can be fully object oriented (Adam says they are mainly "procedural"), take a look (in spite of that code is very old)

 

Alessandro Santini replied on Mon, 2010/05/31 - 9:27am

Sorry guys, I could not resist... http://www.youtube.com/watch?v=oepXF2B5NK4

Ashish Jain replied on Mon, 2010/05/31 - 9:55am in response to: Alessandro Santini

That's exactly I am thinking. I guess, all these design patterns and different web frameworks, have becoming anti-java (aka anti-productivity). I blogged about this long time back Java Products BUT PHP based website Not unified vision is one of major problem, for being JAVA adopted as main stream language for web developers.

Mladen Girazovski replied on Mon, 2010/05/31 - 10:15am in response to: Jose Maria Arranz

service objects can be fully object oriented (Adam says they are mainly "procedural"), take a look (in spite of that code is very old)

Which class are you referering to?

BTW., it's not just Adam saying that ;)

 

Jose Maria Arranz replied on Mon, 2010/05/31 - 10:52am in response to: Mladen Girazovski

All of *RenderImpl classes, they are a hierarchy of Java classes to generate JavaScript DOM code from Java DOM objects (the "data model"), for instance, the JS code needed to create the provided DOM node (including child nodes) in client with JS code. This code could be into the Java DOM nodes (you can if you own the Java DOM implementation) but in my opinion is wrong, very wrong.

 

Yaroslav Hayduk replied on Mon, 2010/05/31 - 3:39pm

http://constv.blogspot.com/2009/08/domain-driven-design-services-and-data.html

 I hope this helps.

Stephane Vaucher replied on Mon, 2010/05/31 - 8:12pm

@Jose Maria - I believe you are voluntarily trying to confuse the domain. Your statement is accurate, but should state that YOUR domain concerns translating Java to JS. The domain reified by the Xerces (or other XML DOM implementation) codebase is on focused on efficiently parsing/accessing generic XML documents. Your requirements and their requirements are different, and as you say, you should not try and pollute their code base with your domain-specific issues.

@Yaroslav - Good link, I would argue that most problems concerning persistence can be linked to impedance mismatch. Until this is resolved, IMHO, we will never find sufficient reason to keep persistence code within a domain entity.

Yaroslav Hayduk replied on Mon, 2010/05/31 - 8:28pm in response to: Stephane Vaucher

Spring Roo does exactly that - it keep persistences code within a domain entity. Well.. the code is not exactly in domain classes but in aspects. This allows to write something like - book.persist() or book.findAll() ..

 

Im not sure that i would want to use such code.. whatif I wanted to save a list of books. Would I do a foreach loop and persist all of them? Nope... I would move such code to a service layer and do it in a batch. But than the business logic gets scattered across service layers and domain layer.. this is how v.1 of the BIG mess begins. 

 

I really like the explanation from the blog that I posted above :

 

Domain entities; those are subjects and actors in the given domain; Domain entity objects must have no knowledge of any application-specific functionality whatsoever. They should not define any persistence logic, nor should they store any direct references to any type of objects that implement data access. For example, some ''UsZipCode'' class may implement such behavior as ZIP validation, parsing of the input data, splitting the ZIP into a 5-digit code, 4-digit extension, or representing itself in several different ways: 5-, 9-, or 11-digit code, etc. All of such functionality is essential to defining the very concept of a US Zip Code. However, it has nothing to do with the world outside the class itself. Nothing in such ZIP Code class depends on, or makes assumptions about, how the objects of the class will be used in applications. Entity definitions must be de-coupled from any external operations that may be performed on the entity instances. The necessity in such operations (use cases) may come and go, but the domain entity objects will remain what they are - regardless of how they are used. It is absolutely valid to expose domain entity objects to the presentation tier (e.g. controllers, form beans, action forms, etc.) and DAOs. If necessary, instances of domain entities may and should be passed between the presentation tier classes and application services in the middle-tier.

Mladen Girazovski replied on Tue, 2010/06/01 - 2:25am

Spring Roo does exactly that - it keep persistences code within a domain entity. Well.. the code is not exactly in domain classes but in aspects. This allows to write something like - book.persist() or book.findAll() ..

Well, this ist NOT DDD!

This is the ActiveRecord Pattern, which is something completely different from DDD.

It throws Persistence code and Domain logic together and violates SoC.

In DDD, you'd have Repositories that take care of persistence logic.

Jose Maria Arranz replied on Tue, 2010/06/01 - 2:30am in response to: Stephane Vaucher

The domain reified by the Xerces (or other XML DOM implementation) codebase is on focused on efficiently parsing/accessing generic XML documents

No, the DOM model is a data model representing a XML node tree and has nothing to do with parsing and serializing. DOM Core API behavior is basically methods to change and navigate through the node tree that is the data model, and some minor utilities for searching nodes (e.g. Document.getElementById(String)) , in fact, these search methods are there for compatibility with past because they are not godd design, more sophisticated search and navigation functionality like XPath or TreeWalker (traversal API), fortunately are defined outside the DOM Core API (the data model of the XML).

 

Jose Maria Arranz replied on Tue, 2010/06/01 - 2:37am in response to: Mladen Girazovski

Yeah you are right, but to speak in favor of Spring Roo, this SoC violation only has to do with "API pollution" of the data model, that is, only plain simple new methods are introduced (injected) into the data model, fortunately most of persistent logic is outside of the data model class in (AOP) aspects.

 

Mladen Girazovski replied on Tue, 2010/06/01 - 2:42am in response to: Jose Maria Arranz

Im not saying that it is the worst design possible, ActiveRecord has its uses, sometimes the "domain" is that simple, it has its advantages and drawbacks, but it has nothing to do with DDD.

 

Mladen Girazovski replied on Tue, 2010/06/01 - 2:45am in response to: Yaroslav Hayduk

  Entity definitions must be de-coupled from any external operations that may be performed on the entity instances. The necessity in such operations (use cases) may come and go, but the domain entity objects will remain what they are - regardless of how they are used. It is absolutely valid to expose domain entity objects to the presentation tier (e.g. controllers, form beans, action forms, etc.) and DAOs. If necessary, instances of domain entities may and should be passed between the presentation tier classes and application services in the middle-tier.

 This is missing the point of DDD completely, you cannot use complex Entites (access to repositories, domain services and so on) in the presentation tier, you must use TransferObjects to communicate with the UI for instance.

DAOs btw. are not part of a DDD model, you call them Repositories there, and they are part of the domain, not part of the technical infrastructure.

 

 

Stephane Vaucher replied on Tue, 2010/06/01 - 4:24pm in response to: Jose Maria Arranz

I spoke of implementors like Xerces and:

"Xerces2 Java is a library for parsing, validating and manipulating XML documents."

That is their domain. Consequently, their DOM implementation needs to provide ways to allow the parsing/validation/manipulation of XML documents. You are getting tangled in details as you are mentioning XPath.

Anyways, you should probably check out a software engineering book as this could help you understand the differences between traditional data centric procedural applications and object-oriented applications. If you want I can recommend a few. FYI, DOM is an object model, not a data model. The two are not synonyms. A DOM is a standardised view of a document. It does not necessarily imply that the information is stored as XML. You could have a DB that presents its data as a DOM tree, and interact with it without knowing it is not XML.

Jose Maria Arranz replied on Tue, 2010/06/01 - 4:34pm in response to: Stephane Vaucher

You are mising the fundamental part of my reasoning.

By the way, DOM and XML markup are two forms of the same "data model", they are the same information (like freezed and liquid water are the same water).

End of discussion.

 

Stephane Vaucher replied on Tue, 2010/06/01 - 5:54pm in response to: Stephane Vaucher

Forgot my ref concerning DOM not being a data model.

http://www.w3.org/TR/DOM-Level-3-Core/introduction.html#ID-E7C30822-h2

Lorena Jam replied on Mon, 2010/10/18 - 11:17am

See when you are dealing with Domain- Driven Development i think their are two imporatants things which you have to kept in mind one is Repository and other is finder.Repository is responsible for storing and retrieving rootsIf you choose a service layer by layer using assign the role of transaction management and authorization. I may be "fine" and do not have domain logic in this country. There is an API for my application. I think all the business voip logic with the domain objects. These include algorithms and validation for the object. The repository is available and the domain objects. This can be a 1-1 correlation between database columns and domain properties for simple systems.

Matthew Browne replied on Sat, 2012/02/25 - 12:55pm

I really wish Martin Fowler had his full description of the domain model pattern up on his website...he has the full article on the "Anemic Domain Model" but only a brief paragraph about the domain model, which has I think only added to the confusion. The full description is in his book of course, but you can also view it here:

http://takacsot.freeblog.hu/Files/martinfowler/domainModel.html

I think this does a good job of showing what the actual purpose of the domain model is supposed to be, and demonstrates that a domain model isn't even necessary in very simple systems that don't have much business logic (although I personally tend to lean toward the domain model for any system that has more complexity than simple CRUD). I also found these links helpful:

http://articles.vconst.com/2009/08/domain-driven-design-services-and-data.html
(shared by one of the commenters above)

http://blogs.infragistics.com/blogs/ambrose_little/archive/2007/10/01/object-thinking-domain-model-example.aspx

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.