<Disclaimer>This is personal notes of what I retained during the session. This can be incomplete, partially right or wrong. It is just  part of the notes I took and what retained my attention. Nothing prevents the user to get more information on their favorite web site.</Disclaimer>

Udi Dahan explains us that today, a lot of books on patterns and practices are existing on the market. But reading them and knowing them by heart does not help if we don’t design the application with flexibility in mind. He takes the examples of the Visitor and the Strategy patterns that could easily be overused by architects leading to a collaps of the application structure. The goal here is not the have an absolute flexibility, but to have flexibility where it makes sense and where it is needed. The same phenomenon occured with the use of hooks.
So, Mr. Dahan tells us that we should make the roles explicit and by implementing them with interfaces. Before, when we had an entity that needed to be validated, we implemented a .Validate() method in the entity. That made sense, because only that entity was able to know how to validate itself. But, what happends if in the entity, another one is linked that, in turns, need to be validated. It could be fine if the call sequence was always the same. If it is not, then the trouble comes. Then, the goal is to identify the roles and to make them as interfaces. So, in the case of a validator, an entity templated (“<T entity>”) interface should be created and a specific entity validator implementing this interface should be implemented as well, so that a Service Locator can return such entity that will be called for validation.
It is also possible to use that same pattern to differentiate the roles that can be applied to a same entity. Mr. Dahan uses that same pattern to implement message handler.