Business Object, Domain Object, and Entity Object; also Façade Object, Workflow Object (or Process Object), and Data Transfer Object

Business Object, Domain Object, and Entity Object; also Façade Object, Workflow Object (or Process Object), and Data Transfer Object


As always, I read vikas’s blog. His recent post: http://vikasnetdev.blogspot.com/2006/07/soa-friendly-architecture-version-of.html , which links to http://codebetter.com/blogs/jeffrey.palermo/archive/2005/04/02/128598.aspx , reminded me the confusing terms used in the typical enterprise architecture – yes, I am saying that there is only one typical enterprise architecture; but there are many terms referring to the same thing.

The rest of this blog has two parts: a long background talk, and a short comment on the blogs of vikas’s and Jeffrey’s.


1. Long Background:

It started in Java. The best and also most influential two books are: “Core J2EE patterns” (http://java.sun.com/blueprints/corej2eepatterns/ ) and “EJB Design Patterns” (http://www.theserverside.com/tt/books/wiley/EJBDesignPatterns/index.tss). Those books and related efforts standardized the terms used in Java community.

However, old habits die hard. There is a widespread -- almost ubiquitous -- confusion, because of the double meaning of “Business Objects”: on the one hand, it means the “Domain Object”, which contains no methods that call database access code; on the other hand, it means the “Façade Object”, which contains methods that call the Data Access Layer, which specifically contains database access code.

OK, in order to clarify the confusion, in the above paragraph, I have to use the terms “Domain Object” and “Façade Object”. However, in the domain modeling “movement”, the term “Domain Object” has the same fate as that of the “Business Object”! Now, we have to use “Entity Object” to refer the same thing. In .net world, this is just perfect; in Java world, the term is close to "EntityBean"-- but it is perhaps a good thing, because it does not have the “bean” in it, and it leverages the similarity.

That is exactly what had been done in MS’s application architecture diagram (http://msdn.microsoft.com/practices/topics/arch/default.aspx?pull=/library/en-us/dnbda/html/distapp.asp ). If you look at it carefully, it is obvious that the diagram is copied from J2EE diagrams – I am not complaining – it is a good thing, especially if you consider that MS does not have a track record in enterprise computing.

There is only one thing in the diagram that I feel I need to complain: the term “Business Components” – it is still very confusing. It should be named as “Business Façade”. Obviously, the term “Business Component” is from M$’s past, the COM – COM is love, and we got to keep some of its trace.

To avoid confusions, I will continue to use “Façade Object” or “Business Façade”, instead of “Business Component”. I understand I am not doing what I am preaching (or implying to preach) -- I am not 100% compliant with M$’s terminology also – old habits die hard.

Another thing that is confusing (but have two different reasons, see below): “Business Workflows”, “Business Components”, “Business Entities” are at the same horizontal line. One reason is that “Business Entities” are used cross tiers/layers. Another reason is that “Business Workflows” should be one level higher than “Business Components”, but sometimes it goes directly to “Data Access Logic”.

“Data Transfer Object (DTO)” is similar to “Entity Object”, because it also does not contain methods that would invoke, directly or indirectly, database access code. However, DTO is even simpler: typically, it does not contain any logic at all. Also, it can be very ad hoc, determined by some UI (or Database) needs, while “Domain Object” is determined by the domain knowledge/logic.

2. a short comment on the blogs of vikas’s and Jeffrey’s

If you look at the diagrams in vikas’s and Jeffrey’s
http://vikasnetdev.blogspot.com/2006/07/soa-friendly-architecture-version-of.html http://codebetter.com/blogs/jeffrey.palermo/archive/2005/04/02/128598.aspx , you will find that they used other terms:

“Business Object Manager” (I guess it is the “Façade Object” -- it is very popular to use "XX_Manager" and "XX_Facade" interchangably)

“Process Object” (I guess it is the “Workflow Object”)

“Repository Object” (I’m pretty sure it is the “Façade Object”).

Perhaps my guesses are not correct: are there any differences between M$’s application architecture and the ones in vikas’s or Jeffrey’s? -- Yes, I am trying to advocate we use M$'s terminology at least as a "reference". Again, I realize that I am already guilty of not compliant when I use "Business Façade”, instead of “Business Component”.

By the way, I understand a lot of people feel “application architectures” and “service architectures” are critically different, but I am totally not convinced, so, I use them interchangeably: any not-short-sighted application architecture must also be a “service architecture”, and any not-just-an-air-ware service architecture must also be an application architecture.