Friday, July 21, 2006

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: , which links to , 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” ( ) and “EJB Design Patterns” ( 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 ( ). 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 , 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.


Blogger Vikas said...

Excellent Questions.

When I was naming my architecture I was weighing between Ready for Distributed Computing and Service Oriented Architecture Ready. I went for buzzword (I knew that I am going to get in trouble with you) :)

7/27/2006 06:56:00 PM  
Blogger survic said...

(I also posted this to Vikas's blog: )

I noticed you mentioned three things at the end of your post (a) “It is more Document Style of communication”; (b) “SOA is more like workflow”; (c) “However I think that if you have good Middle Layer, adding a true service layer should be a small issue”.

My whole arguments are based on those three points. If you build entity objects (including containment – i.e. “aggregated entity objects, and also including “value objects”) and some necessary DTOs (data transfer objects), then, they can be changed to XML easily. Then, when it is necessary, we can simply select some façade and workflow objects as the services. Perhaps sometimes we need to make it even more coarse-grained; but we do that all the time within façade and workflow layers anyway– that is the very nature of façade and workflow layers: constantly changing to reflect business workflow/use-case changes.

Put it in another way: in classic asp or servlet or cgi (note that hides more, so, I would not use it here as an explanation tool, but I will use it later, see below), the response is html based; web service is xml based. That is the only real difference. You may say, “we need more standards and therefore specs in web services”, true, but that is what xml implies.

However, we all know and classic asp are both in the “application architecture”. makes things more like winform by using postback. Ajax/Atlas makes it even more so.

I guess we can safely say that we all agree that SOA is adding (not changing, simply adding) another half a layer (not even a whole layer) that is similar to “workflow” layer, and is more document-oriented and message-oriented communication.

As for the differences, they really depend on the context. I can easily imagine that I can argue a SOA is very different from an Application Architecture when I am focusing designing the half layer of the service, when I need to zoom in, and amplify details.

I guess the key reasons that I want to point out that there are not big differences are that (a) SOA’s new stuff is an addition; (b) the crucial business logic (“domain logic”) is in the business layer. As a result, for an application developer, SOA is the plumbing, or, even just a “distraction”. (My impression is that Rocky also holds the same attitude, but via a different route though – very interesting)

7/30/2006 03:30:00 PM  
Blogger survic said...

A correction: "repository" is not just "facade", it is between "facade" and "DAO"; it is more DAO with caching and object-graph concept.

This is indeed another example that while trying to "abstract" away database, people are re-inventing all those terms. But database is a significant reality, it cannot be abstracted away -- "repository" has obvious database implications: if it does not have it now, it will soon -- when people learn to equal it with “DAO”: a repository is a feature-rich DAO, period.

I appreciate the dynamic creativity of those term-re-inventing, we do need it in order to keep us awaking and thinking; however, I do not actively follow them anymore: when I meet an interesting one, I look it up.

7/30/2006 09:09:00 PM  
Blogger Vikas said...

Survic wrote
"I guess we can safely say that we all agree that SOA is adding (not changing, simply adding) another half a layer (not even a whole layer) that is similar to “workflow” layer, and is more document-oriented and message-oriented communication.

One thing that I think that driving this layer with out requirements is very difficult to derive. With out requirement, one is simply shooting in dark and will cause him despair. But if you have requirements, this layer is very easy to add

8/14/2006 07:10:00 PM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home