Domain Driven Development and Rich GUI

I have a philosophical question about applying DDD to development of a rich GUI application. As a programmer I have experience in creating both DDD and DB-oriented systems so I know the basics. Now I am facing a complete redesign of a large point of sale application and I have a problem.

Usually DDD concept means "99% of logic is in domain and 1% of logic in GUI"; and logic in GUI is only a validation. Such approach works well when you have simple forms, where users can enter something and then press 'Save' to send the data to a server or smth like this.

One of the main features of the existing application is that it's quick. Working on POS means a saleperson does everything quickly. Business logic that the POS must follow is highly complicated. Roughly speaking, every time a user changes price, tax, discount etc other prices, dicounts, taxes etc changes; so it's a kind of a domain that resides on a client.

Technically I can, obviously, move the logic to a remote domain that lives on a server, but it will make the system very slow. I'll need to make a remote call every time a user makes changes in UI.

Are there any ideas of how to preserve purity of DDD and at the same time make the system quick?

Thank you!

P.S. The only way I see now is using a downlodable assembly that contains a domain, but it defini开发者_Go百科tely looks like a hack...

There is a definite trade-off that needs to be carefully managed to find the right balance between UI responsiveness and enforcing the purity of DDD.

Personally, I like to to take a default position of starting "pure" and only allowing compromises to the DDD pattern where real world performance testing proves it to be necessary.

I often find it is surprising how much of the logic can be kept on the server without adversely affecting client responsiveness, since the bottleneck is not necessarily where you expect it to be.

One concept is to have some quick validation on the client, which does not try to be 100% accurate but can detect maybe 95% of invalid input.

In your example this quick validation could check things like:

• discount is greater than 0 and < price
• tax somewhere between 0 and 25%

The input is sent to the server for full validation only if it has passed the quick client test.

For example - assume we have a quick client side validation which is 95% accurate. This means that when the user inputs invalid data, in 95% of cases the UI will display the error with no server contact necessary.

Only 5% of invalid input data will result in an error being displayed first after server contact. Which is probably OK if the user usually does not supply invalid data - which partly depends on how well designed the UI is.

Critical - the quick validation must never say that valid data is invalid.

probably you can try, to use separated "two applications" (two modules) each one as in DDD philosophy: - customer service in the POS - shop services in the "server"... the two modules have to by integrated... e.g. via network...