We just had the privilege of hosting Eric Evans for half an hour at our project!
quick summary of what i scrawled down.
1) The MODEL : it was very clear to me that the model is neither a diagram, documentation or (which was the most interesting to me) the code. Quite often in agile we hear about the code being king! the code is the design, etc. Actually the model is an abstraction of all of these. THe code is the current expression of that abstraction and is therefore the only solid thing you have available. UML and documentation (he mentioned writing up key abstractions in the model such as Page – these could be made highly visible on walls or so) are TRANSIENT and provide a particular view of the model at any one time which can be useful for communication but is not necessarly the LAW.
2) Services : Should be orchestration rather than containing a lot of logic. The logic should be presented by the domain entities. Anything complex lives there, services should represent clearly defined abstractions of doing a particular thing. They can also represent an easy interface to the complexity of the domain.
To aid with design decisions about what should live in the service or the entity it helps to have a clear MODEL worked out and understood by everyone. The model will tell you where to put stuff, or it will feel more natural, it will guide you.
3) Model context boundaries: This is something interesting in the DDD book – models only have relevance within specific context and so it is important to define that context and anything that crosses the boundary must be translated into the other context.
4) Crossing boundaries or interacting with other domain models. There are 2 strategies, Conformist or Anti-corruption layer Conformist means to take the same object model. Anti-corruption layer means to build an adapter between the two contexts.
5) We have 2 clients of our Domain objects, people who edit content and the people who design the front end pages using velocit and CSS. We asked the question as to wether there should be additional translation into the front end “model”. Perhaps there are 2 domain contexts’ here? The thought was that for our system it might be better to keep the core model as a set of concepts and just exntend those concepts to provide a more useful interactio with the presentation layer. One of the problems is classes getting really big, so maybe splitting them up into smaller, functionally cohesive units which are more suitable for different applications.
By the same token we should be extracting the CONCEPTS from the front end and building them into the model. This totally highlights the idea that the model is a conceptual abstraction of the software, not a particular artifcat such as the code or a diagram.
We have been more focused on the content building side and have done good work modelling the domain from that aspect, potentially we need to move that modelling into the front end.
6) MODELLING is different to Software DESIGN : this is not something he said but something i think might be implied by the modelling stuff.
If the MODEL is not the CODE, it cannot be the design of the software. Therefore, MODELLING as an activity is a more abstract than writing the code – the DESIGN of th ecode should fall out if the model is well defined and understood. The MODEL is more about principals and ENTITIES than low leve code design.
What a great afternoon!
Subscribe