5

i am starting to implement an enterprise app using DDD guidelines. First of all, me and my team are starting our journey through DDD, so we have lot of things to learn and to understand (so forgive me if i say something...stupid=>)

The app will be a (very customized) CMS. The project will have:

  • Domain and Backend developed using Microsoft stack (C#, WebAPI, EF6)
  • Front-End developed as SPA using AngularJs

My biggest doubts are related to how (and how much) it will be possible to use the domain in a rich client application...i mean, if all the logic resides in the domain objects (back-end side), how should the communication between FE and BE be developed? Should the system do a sort of ping pong game for every changes done on the entities on FE side?

Or should i take some compromise? Anybody had a previous similar experience?

Gnegno
  • 366
  • 1
  • 5
  • 15
  • 2
    question title can be improved. 'is a good idea' asks for opinion. How can I reduce the amount of ping--pong needed when... asks for concrete solutions – Stephan Eggermont Apr 27 '15 at 16:57
  • 3
    Your question is *very* broad. Well, the answer can be rather long :) --- I tend to think of a domain as an old physical calculator. It has a mechanism to input data / behaviour (keypad) and an output mechanism (screen / printer). Whatever input or output mechanism you use does not affect the domain. It is isolated and performs some business functionality. Hope that helps ever-so-slightly :) – Eben Roux Apr 28 '15 at 06:03
  • I'm sorry for the broad and unclear question, you are all right. Actually i'm trying to clear my mind a little bit having a deeper look at implementing the CQRS pattern in my solution in order to correctly decouple interests and responsibilities. – Gnegno Apr 28 '15 at 10:02
  • 1
    @Gnegno A rich domain is helpful mainly to ensure the consistency of the writes. The UI may call on the domain for some business rules enforcement (web services), but most of the simple validation rules can simply be duplicated in the UI. I know, it seems hard to accept, but trying to extract business rules from your domain objects automatically and map them to UI view models is introducing way too much coupling and will probably end up being much more harder to maintain. – plalx Apr 28 '15 at 16:23
  • "Should the system do a sort of ping pong game for every changes done on the entities on FE side". Every command that has to be processed will have to be sent to the backend, yes. DDD works best with a task-based UIs. – plalx Apr 28 '15 at 16:25

2 Answers2

1

You probably want to generate the front-end from the domain. Generate client-side validations and calculations from your domain-side descriptions. Once it works, you can make your generator smart in that it starts using information about the amount of ping-pong needed (and even actual delay and throughput) to do caching

Stephan Eggermont
  • 15,847
  • 1
  • 38
  • 65
  • Thanks for your hint. I was wrongly thinking of moving my domain entities to AND from my front-end (i mean, sending the domain object to angular and returning back to backend a serialized version of the modified one...just a big mess and obviously something that couldn't work much). I'm taking a look at implementing CQRS pattern in order to avoid that kind of errors and i'm slowly understanding how (probably) things should be done. – Gnegno Apr 28 '15 at 10:06
  • I think it's better not to be DRY than introducing a large amount of coupling by trying to extract the rules from the domain to be used in the UI. – plalx Apr 28 '15 at 16:18
  • @plaix I'm very sure it is better to DRY than duplicate and manage the coupling by hand, which is the alternative – Stephan Eggermont Apr 28 '15 at 19:07
  • 1
    @StephanEggermont Did you actually try it with a rich always-valid domain which is taking advantage of modeling strategies such as Value Objects? Extracting business rules may be easy for CRUD systems, but would be very hard in a properly modeled DDD system IMHO. Most validations that can occur on the client are trivial and there's already a lot of frameworks that will let you define them efficiently. If it was that simple, no one would be writing about that and the problem would have been solved a long time ago. – plalx Jun 05 '15 at 04:17
  • You may want to read my answer here: http://stackoverflow.com/questions/28395176/should-i-abstract-the-validation-framework-from-domain-layer/28397201#28397201 and this article http://gorodinski.com/blog/2012/05/19/validation-in-domain-driven-design-ddd/ – plalx Jun 05 '15 at 04:22
  • I'm pretty happy with a declarative description (originally http://scg.unibe.ch/archive/papers/Reng07aMagritte.pdf , since extended). I also know that having solved a problem is absolutely not-relevant for the writing about it: The Gemstone OODB made RDBMS and ORM irrelevant for databases < 1TB more than 20 years ago. Tech communities move at different speeds – Stephan Eggermont Jun 08 '15 at 09:47
1

There nothing in DDD that could prevent you from having it as a back-end for any sort of UI. Nearly any system that is build using DDD it its back-end has some sort of the UI.

In particular, read more about task based UI and REST APIs. You will need to have commands coming to your domain from the front-end, based on tasks that your users perform. You can do preliminary validation like mandatory fields and data types, in the front end side, and business validation and command handling in your domain. All the communication is done using REST API to your domain, which will be an adaptor between your domain and the UI.

Also, SPAs with REST APIs behind are very suitable for CQRS.

Do not exchange your entities between FE and BE. Always you DTOs for data transfer.

Alexey Zimarev
  • 17,944
  • 2
  • 55
  • 83
  • 1
    +1 for DTOs...i was wrongly thinking that using a JSON from my domain entity was enough but i smashed my face on problems that are all but domain concerns. – Gnegno May 04 '15 at 07:08
  • It is never a good idea to leat your entities leaking outside of the domain, would this be UI or another system. – Alexey Zimarev May 04 '15 at 07:16