• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

domain objects as DTO's

 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,

We are trying to follow a domain driven design approach. One question which cropped up is when we model domain concepts as distinct classes and have all the business logic part of it.
Say we have a domain concept like Customer and there can be 3 different types of Customer (TypeACustomer, TypeBCustomer, TypeCCustomer). So each of these classes will consist of business methods specific to the respective type and no common processor class having bunch of if-else logic jumping between blocks related to these types.

Now the instances of these Customer types don't originate in the application but are exposed to external apps which initialize the instances of these types and pass it to the application.
My question is it a common practice to expose the domain class instances as input/output data transfer objects also.
Since they contain all business logic should they be hidden from the external entities. If yes how is the separation normally/popularly achieved.

Thanks.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34839
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Manish,
DTOs are usually dumb objects that are used just for transfering data. If it has business logic, it's not a DTO by definition. This doesn't mean you can't use it to transfer data though.

I would use a real DTO if passing it outside the application. Just to minimize the impact when the business rules change.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, at first it would be nice to clarify that we would use DTO only if we have remote interfaces.
If we don't use remote interfaces, just don't use DTO, end of story.

DTO has nothing to do with any business rule, its main purpose is to reduce number of remote calls.
I mean they are not supposed to minimize impacts when business rules have changed, that is just not the purpose of this pattern.

To the topic creator, I'm not sure I fully understand what you want to do, could you please to give an example?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kengkaj Sathianpantarit wrote:
DTO has nothing to do with any business rule, its main purpose is to reduce number of remote calls.
I mean they are not supposed to minimize impacts when business rules have changed, that is just not the purpose of this pattern.


Exactly. More specifically, their purpose is to transfer data in one single object (the DTO) that otherwise we would have to be transfer a whole number of Business Objects for.

If you want to reduce coupling between your application and external applications (which you probably should), you can use factories and interfaces instead. That way, the external applications can create and pass in your Business Objects without even knowing.
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well I was not saying having business logic in DTO's.

What i was trying to imply is to have a class for each domain concept type. TypeACustomer, TypeBCustomer etc
So all specific attributes will reside in these respective classes. The business logic for the same will also be contained in these classes.

Now the way the instances of the aforementioned domain classes get populated is by an external app. So should we be maintaining a separate DTO layer just as mere data containers and then pass on to the domain classes or I can use the domain classes (TypeACustomer, TypeBCustomer etc) as data containers.

Manish
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What you mean by "domain classes get populated is by an external app"?
You mean an external app instantiates domain objects or you mean something else?

How does your application communicate with this external app? You use Socket, RMI, Web Services, JMS or something?
Please give more information.
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are two types of external apps. One is pure java client app and the other is a web service.

The external app has to provide input data. So there are two options 1) expose dumb dto container objects which will be populated by the external apps and appropriate app functionality invoke passing in the dto's. The application functionality unwraps the dto and passes the input to specific business logic handlers which pass them down to domain objects (actual business logic processors).

option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.

I would like to know your thoughts on this as I feel I can avoid the extra dto layer or the better approach in this type of scenario.

Thanks- Manish

 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
manish ahuja wrote:
option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.

If you mean remote interface and you want to reduce remote calls, using DTO is a good option.
If the client apps invoke a method on the domain object, it will call remote method on the server, because processing must happen on the server-side. You understand this right?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kengkaj Sathianpantarit wrote:
manish ahuja wrote:
option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.

If you mean remote interface and you want to reduce remote calls, using DTO is a good option.
If the client apps invoke a method on the domain object, it will call remote method on the server, because processing must happen on the server-side. You understand this right?


That's not necessarily true. If the functionality in the domain object is self-contained (that is, it doesn't need other server functionality), the DO could just be serializable and the business logic executed on client side.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is possibly a third option, as I tried to say above: only expose interfaces to the client. That's especially simple if the client is actually running in the same JVM.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja Preuss wrote:
Kengkaj Sathianpantarit wrote:
manish ahuja wrote:
option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.

If you mean remote interface and you want to reduce remote calls, using DTO is a good option.
If the client apps invoke a method on the domain object, it will call remote method on the server, because processing must happen on the server-side. You understand this right?


That's not necessarily true. If the functionality in the domain object is self-contained (that is, it doesn't need other server functionality), the DO could just be serializable and the business logic executed on client side.

In sever-client applications, it's very rare for the client to be able to execute business logic on its own. Even in that case it is strange that why the server needs to send a domain object to the client, the server can send just a command String (or any kind of data the client can parse), and the client can create domain object and execute a method on its side. So no need to send an object.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I was not so sure, what the topic creator really wanted. So I repeated many times that TO/DTO is for reducing networks calls.

Ilja Preuss wrote:There is possibly a third option, as I tried to say above: only expose interfaces to the client. That's especially simple if the client is actually running in the same JVM.

Just to clarify, this is not true in the case of using Entity Beans, even if the client and the bean are in the same JVM, the remote invocations still use network layer.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kengkaj Sathianpantarit wrote:
In sever-client applications, it's very rare for the client to be able to execute business logic on its own.


Well, I'm actually working on exactly such an application. Don't care how rare it is - it's a valid option.

Even in that case it is strange that why the server needs to send a domain object to the client, the server can send just a command String (or any kind of data the client can parse), and the client can create domain object and execute a method on its side. So no need to send an object.


I don't understand the differentiation you are making. A serialized object is nothing more than data the client can parse. Only that the parsing (and serialization) is taken care of by the Java platform.

So, asked the other way around: why invest into dealing with sending command strings or parsing data and creating domain objects out of it, if you can just send an object?
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja Preuss wrote:
Kengkaj Sathianpantarit wrote:Even in that case it is strange that why the server needs to send a domain object to the client, the server can send just a command String (or any kind of data the client can parse), and the client can create domain object and execute a method on its side. So no need to send an object.


I don't understand the differentiation you are making. A serialized object is nothing more than data the client can parse. Only that the parsing (and serialization) is taken care of by the Java platform.

So, asked the other way around: why invest into dealing with sending command strings or parsing data and creating domain objects out of it, if you can just send an object?

The different is if we send a command string we can send only data that is necessary, on the other hand sending a domain object means sending unnecessary data like class definition.

For example if we have a domain object of the following class:

In case the client just want data, the server can send a string like {"prop1":100,"prop2":200} rather than an serialized Java object which contain unnecessary class definition. This is better in terms of data size, it can improve performance in case there are many communications between the server and the clients.

Sending string is also more flexible in case we want to support non-Java clients.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, the class definition is typically *not* sent when serialize an object. Just the object's data, and some metadata.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The serialized object will contain qualified class name and attribute metadata. Actually, this is minor point.
If the size of data is not very important or the application supports only Java clients, sending serialized Java objects is fine.

The another advantage of sending only data is we can design domain object class in client and server independently. For example, we can have business methods specific to client side in DomainObjectClient, and we can have business methods specific to server side in DomainObject (or DomainObjectServer).

But in case that all of business methods in DomainObject can be executed meaningfully in both client side and server side, sending domain objects from the server to the client is fine.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic