Share model between client and server

Question

Due to our domain model and process, we are looking for a sharing model between client and server. Our client is really thick client. Is there any information about such architecture, pros and cons?

Ornstead

Answer 1

Theoretically if your Domain layer is totally decoupled (from persistence, presentation, infrastructure, etc.) it can easily be reused as a library in different places.

However, as Adrian points out, this raises practical issues :

• Security : distributing your domain especially in client applications can be risky. One way around that is to obfuscate your binaries if the client is a desktop app.

• Platform mismatch : you might not be able to use the same technology/language on client and server. This will result in a translation of your domain, basically doubling the initial amount of work, maintenance cost and bug proneness.

• Versioning : even if the same library is reused, its versions on the client and server must probably be kept in sync to prevent incompatibilities.

Besides, except if you're developing a web version that is an exact clone of a desktop version, I feel that the domain reuse will be partial at best. In the case of a single client/server application, I'm curious to know why you would use the same domain on both tiers... usually what you have on the client side is data structures that might look a bit like the domain entities, but tweaked for the UI, and with no behavior. In that case, reusing the whole domain layer on the client side would mean dragging along a bulky object graph that maybe partly does what you need but also a ton of other unneeded stuff.

Maybe what you need instead is the concept of Bounded Context from Domain Driven Design - same class names but slightly different classes in Client context and Server context.

Vitebsk

My question was poorly detailed. We develop software for internal purpose of our company. So, i think, there are no big problems with security. We have one platform and one version also. And i think about reusing domain entities on client, because, both client and server entities are very similar. Thanks. – Ornstead

Answer 2

DDD and modern development practices encourage keeping domain logic out of the client. Most of the code happening in the client-side these days is there to leverage the GUI goodness of the client platform.

Two good reasons for keeping domain logic out of the client are security and maintainability.

For security, the server should regulate what the client can do. The client can be hacked to bits, but if all the domain logic and security are in the server, then no amount of hacking (on the client) can circumvent or damage the system.

For maintainability, if all your domain logic is on the server, then it's in one place. If it's in one place (or better still in a clearly defined module or namespace) then it's easier for anyone on the team to maintain the code.

Tellurize

Please, look at my comment to guillaume31 below. – Ornstead