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 definitely 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.