DDD and client / server applications

Question

I was wondering if any of you have successfully completed DDD in the Client / Server application and would like to share some impressions.

We are currently working on a smart client in Flex and a backend in Java. On the server, we have a service level open to the client that offers CRUD operations among some other service methods. I understand that in DDD, these services must be repositories and services that must be used to handle use cases that do not fit inside the repository. Right now, we mimic these services on the client behind the interface and implement implementations (Webservices, RMI, etc.) through the IoC container.

So, some questions arise:

• if the server exposes the repositories to the client or we need to have some kind of facade (which, for example, is able to handle security)
• should the client implement repositories (and DDD in general?), knowing that most of the logic on the client is related to viewing, and the real business logic lives on the server. All communication with the server occurs asynchronously, and we have one programming model with a thread on the client.
• how about mapping a client to server objects and vice versa? We tried DTO, but went back to expose the state of our objects and correlate them directly with them. I know this is considered bad practice, but it saves us an incredible amount of time).

In general, I think the new generation of applications is coming with the rise of Flex, Silverlight, JavaFX, and I'm curious how DDD fits into that.

Answer 1

• I would not publish the repositories directly to the client. The first big issue that you mention is security: you cannot trust the client, so you cannot provide data access APIs to potentially hostile clients.
• Wrap your repositories with services on the server and create a thin delegate layer in the client that handles the remote connection.
• Identifying your entities is not necessarily a bad practice, as it becomes problematic when you start to consider things like lazy loading, sending data over a wire that the client does not need, etc. If you are writing a DTO class that wraps one or more objects, and delegates receive / set calls, you can quickly create a DTO level, especially using the code generation available in most IDEs.

The key to all of this is that the template set should only apply to part of your application, and not to everything. The fact that you have rich logic in your domain model and using repositories to access data as part of DDD does not affect the client. It is clear that the RIA that I create has three levels:

• The client uses something like MVC, MVP, or MVVM to represent the user interface. The model layer ultimately causes ...

• What can I call the "Integration Level". This is a contract for services and data objects that exist on both the client and the server to allow the two to coordinate. Usually, the user interface design controls this layer, so that (A) only the data that the client needs is transferred to it, and (B) access to the data can be coarse, that is, “make one method call for the entire state required for this set of user interface.

• A server using everything that wants to process business logic and data access. It can be DDD or something else an older school, for example, a data layer built using stored procedures in the database and many objects "ResultSet" or "DataTable".

The fact is that the client and server are very different animals, and they must be changed independently. To do this, you need a layer between them, which is a fair compromise between the needs of the user interface and the reality of how everything can be on the server.

The only big advantage that Silverlight / WPF and JavaFX uses for Flex + is that you can use a lot of logic in the first two, because you have the same virtual machine on both sides of the application. Flex is the best user interface technology, but it lacks a server component where code can be shared and reused more efficiently.