With the popularisation of DDD people started shifting from anemic models with only getters and setters to a rich model describing the state changes in specific methods. This way of designing models does not play well with Symfony forms. User provided input is inherently invalid while we want to maintain certain invariants in our domain model. A common approach to overcome these limitations is to create data transfer objects our forms are then bound to. This can lead to lots of mapping & glue code that might be cumbersome to write and maintain. But couldn’t we do better? In this talk we will discuss the different aspects of a rich domain model that makes it hard to use it in conjunction with the Form component. We will then look at the possibilities to hook into the data flow of the form handling and discover how we can modify it to interact seamlessly with our model.


Comments are closed.

Tom Adam at 14:23 on 6 Dec 2018

I really enjoyed this talk. I have been moving towards rich domain models and immutable value objects recently and have found the same challenges presented in this talk. The double act worked well. Looking forward to the future of the bundle.

Amir Iskander at 14:53 on 6 Dec 2018

The talk was really brilliant and informative, I appreciate if they can send the slides.

David Buchmann at 17:05 on 6 Dec 2018

A great summary of the capabilities of the form layer and a good motivation for why to add extra things on top!

Miro Svrtan at 17:59 on 6 Dec 2018

It was interesting to see a duet of speakers, they got it working pretty great but I'm not sure that there was that much difference in context to go for a duo ... However, interesting idea and done pretty good

On the content, I think intro with showing Entities/Forms/etc can be bit shorter as this was SymfonyCon and I dont really know any devs who have avoided entities/controllers or forms while working on it (not sure there are many non-experience Sf devs coming to a conference like this but I might be wrong).

Interesting idea with the RichModelFormBundle, will for sure check it out (but I do have some reservations on part that it's better to write config files for a 3rd party module vs writing more code)

Johan Vervloet at 20:58 on 6 Dec 2018

Good overview of the different ways to use Symfony forms with rich model entities. We were wondering if/how the rich domain form bundle could fit in a CQRS-scenario, when you have to prefill the form with data from a read model, and submitting the form needs to return a command or command stream.

Javier Eguiluz at 07:25 on 7 Dec 2018

I liked a lot of things in this talk:

1) Topics were introduced in a ver understandable manner so people who didn't know about them could follow the talk ... but the introductions weren't long enough to bore people who already know that.

2) Each solution was presented with both advantages and disadvantages. Everything was really presented with tradeoffs instead of dogmatism. We miss that in lots of tech talks.

3) There was a lot of work behind the slides: the useful and never annoying animations, the right font sizes (using smaller fonts for unimportant things), the very clear summary slides, the overall design based on form elements (such as using checkboxes as the bullet of lists), etc.

Thanks for this great talk!

Bruno Paz at 21:42 on 7 Dec 2018

Expected sone more advanced DDD techniques than just create a mapper function in the form. Also Data transformers should probably be considered in that case.

Not a big deal, but the code examples had same inconsistenties like docblock not matching the implementation.

Bram Cordie at 11:17 on 9 Dec 2018

This was a nice refresher of the possible approaches you can take when passing simple domain classes back and forth the form component.
The speakers did a good job on covering as much as possible using some common examples that might be intimidating for beginners. I would have been nice if they showed more advanced things and really put forth the power of these rich models. When you are working with complex domains you often can't just map forms and domain classes one-to-one. The original data for your form might be coming from a read-model, resulting in a stream of commands that is sent to your write-model.

The speaker combination worked really well, and I loved how the talk was set up clearly explaining pros and cons of the different ways to use the form component for rich domain models.

Informative and interesting for a very precise use-case

Good content and presentation, I was probably expecting something more than just this very specific case.