Remoting and Anemic Anti Pattern

[baronludwig]

Hi
Would appreciate any feedback / recommendations regarding our current application architecture.

Broadly, it is currently as follows:

Client: (Access to Service Layer is controlled through Spring)
Swing Rich Client (JGoodies, JForm Designer...)
Spring HTTP Remoting communicating with..

App Server: (All objects on the server are controlled through Spring)
Service Layer Pattern using....
Data Access Objects using ...
Toplink ORM to map to legacy database.

State only exists on the Client.

Currently, we have a Business Domain, instances of which exist on the Client and on the Server (but only for the lifetime of a partilcuar remote call).

We believe that this Business Domain, shows all the features of an anemic domain model (http://www.martinfowler.com/bliki/An...mainModel.html) due to the use of remoting and the service layer to execute business logic and provide CRUD opertations on the persistent data store.

As part of refactoring this Business Domain (it also currently too closely resembles the legacy database) I am proposing to combine the calls to the service layer within the Business Domain.

For example, we currently have a Client Object. To "getAddresses" we call the ClientSO.getAddresses and populate the "address" property within the Client Object.

I now intend to to implement the call to the ClientSO.getAddresses method, within the Business Domain, Client.getAddresses method.

Does this appear to be a correct thing to do?
Also, is it worth implementing the new features withing Spring 2.0, to use AspectJ to dependency inject domain objects.

Any feedback greatly appreciated.

Regards
Marc

[Alarmnummer]

My personal opinion is that Domain Objects (even not Anemic ones) shouldn't be distributed to the client. It tightly couples the client to the server and it could give serious issues with the amount of data being transfered.

I would use DTO's instead. With DTO's you know exactly what data is going to be transfered and it also loosens the coupling between client en server.

[rgeorgiev]

The problem with Rich Domains, is how to handle serialization . You need somehow to inject repositories,etc. there. One solution is to make it with AspectJ on getter call, so they will be available after deserializing.

But I prefer for now to use DTO(Value Objects) when dealing with remote services.

[baronludwig]

I certainly aggree that the use of DTOs is applicable in most remoting scenarios. However, I still (currently ) believe that in our particular proposed architecture, the actual Domain Objects are more useful and can be transferred using our particular remoting choice (HTTPInvoker).

Our app server layer is intended to be stateless, and elements of the Business Domain only exist for the lifecyle of a particular operation against the persistence layer (Spring POJOs/DAOs/ORM/RDBMS).

State does exist on the client (a Rich Swing app), and I therefore want to make use of our hopefully rich Domain Model, without the need to retrieve DTOs, and then instantiate richer Domain Objects from these.

Currently, I'm considering if this can be achieved by using the new AspectJ integration in 2.0 exactly as you say. In effect, I think that the Business Domain exists as a stripe across all architectural layers of the system, and Spring Aspects / DI will specify how the request for Aggregates are fulfilled, dependent on whether the objects is being instantiated on the client (though constructor) or app server (via ORM).

Also, thinking that Aggregates (as defined within Domain Driven Design) should be used in order to set the boundaries where services are used to access or persist the objects via the application server.

The major struggle I have is to merge the Business Domain, and our current Service Layer, to avoid our currently anemic model. Not so worried about coupling between client and server as we are in control of both, but certainly would be if we were not.

Appreciate any thoughts, particularly if strong disagreement!

Marc

[manifoldronin]

My personal opinion is that Domain Objects (even not Anemic ones) shouldn't be distributed to the client. It tightly couples the client to the server and it could give serious issues with the amount of data being transfered.

I would use DTO's instead. With DTO's you know exactly what data is going to be transfered and it also loosens the coupling between client en server.

I fail to see how domain objects would couple the client to the server any more tightly than DTO's would. After all, most DTO's are basically "behaviorless" replica of corresponding DO's, aren't they?

Of course the client would couple more tightly to the Domain Model, but that should be a good thing IMHO.

[Alarmnummer]

I fail to see how domain objects would couple the client to the server any more tightly than DTO's would.

If you don't use DTO's, every change in the DO, will be visible in the client -> tight coupling. If you use DTO's, not all changes have to lead to a change in the client. What if you rename a field? Add a field? Rename the class? This doesn't have to lead to a change in the DTO and in turn won't lead to a change in the client -> loose coupling.

After all, most DTO's are basically "behaviorless" replica of corresponding DO's, aren't they?

even if they were, I don't like tight coupling.

Of course the client would couple more tightly to the Domain Model, but that should be a good thing IMHO.

Why is this a good thing? If I expose my domain objects directly by a webservice for example, and I decide to rename a field, all clients need to be changed. Why is this a good thing?

[Alarmnummer]

I certainly aggree that the use of DTOs is applicable in most remoting scenarios. However, I still (currently ) believe that in our particular proposed architecture, the actual Domain Objects are more useful and can be transferred using our particular remoting choice (HTTPInvoker).

Why are they more usefull? And exposing domain objects directly can lead to serious problems like security or ignoring class invariants.

Our app server layer is intended to be stateless, and elements of the Business Domain only exist for the lifecyle of a particular operation against the persistence layer (Spring POJOs/DAOs/ORM/RDBMS).

I don't see why this is important for this discussion (it is the way I like to write my applications also btw

State does exist on the client (a Rich Swing app), and I therefore want to make use of our hopefully rich Domain Model, without the need to retrieve DTOs, and then instantiate richer Domain Objects from these.

DTO's are more work than exposing DO directly. But I still prefer using DTO's because it decouples the client from the server, makes it easier to send the right information to the client (with a DTO you have perfect control on what is and isn't send) and the 'saveOrUpdate' method on the server could lead to serious problems like security and ignoring class invariants.

[baronludwig]

Many thanks for the replies. I'm having some trouble organising my thoughts, so apologies for this reading like a brain dump, rather than a considered position!

I certainly aggree that the use of DTOs is applicable in most remoting scenarios. However, I still (currently ) believe that in our particular proposed architecture, the actual Domain Objects are more useful and can be transferred using our particular remoting choice (HTTPInvoker).

Why are they more usefull? And exposing domain objects directly can lead to serious problems like security or ignoring class invariants.

For example, my Domain Model (Aggregate?) is Customer has -> Addresses. If this exists on the client tier having been returned / created using an Injected [remote] service, I can simply traverse to the addresses. I certainly see that this could also be achieved by creating objects based on DTOs, but I don't like the (code) cost of developing them. Also, when thinking of providing future Web Service layer, this will be driven by the contract required, and therefore I can not see any re-use of these DTOs or the application services that provide them.
I think I'm trying to mitigate against having a Smart UI anti-pattern, where all business logic is implemented through Application Services, and the domain model has little value.

Marc

[Wesslan]

I fail to see how domain objects would couple the client to the server any more tightly than DTO's would. After all, most DTO's are basically "behaviorless" replica of corresponding DO's, aren't they?

Of course the client would couple more tightly to the Domain Model, but that should be a good thing IMHO.

We use DTO's (but not Spring ) and we recently changed a bunch of our domain objects. We didn't have to change one thing in the DTO's interfaces to our remote clients. This was very good since we have 10+ different clients (remote systems) that we don't control.

Cheers

[Alarmnummer]

For example, my Domain Model (Aggregate?) is Customer has -> Addresses. If this exists on the client tier having been returned / created using an Injected [remote] service, I can simply traverse to the addresses. I certainly see that this could also be achieved by creating objects based on DTOs, but I don't like the (code) cost of developing them.

I agree that creating DTO's isn't the most fun thing to do, but they are very valuable. And in some cases you can get away with returning domain objects (for example in the presentation layer) but for remoting purposed, I would use DTO's (but that is my personal opinion).

Also, when thinking of providing future Web Service layer, this will be driven by the contract required, and therefore I can not see any re-use of these DTOs or the application services that provide them.

The DTO's are part of that contract. And especially with webservices, you don't want a tight coupling between client and server. Domain objects are 'just' and implementation detail of your service. You don't want anybody to know about it,