My personal notes about books I read
There are three main objects that can control the life-cycle of a domain object:
A model is expressed in code by several patterns of model elements:
In order to easily identify, understand and manipulate the code that reflects the domain, we need to isolate it from all the support code, the code that allows for user interaction (views, controllers) and the code that allows for data persistence and retrieval.
The most widely used and easy to understand approach is to isolate the code into layers:
The implementation design must be easily and accurately mapped to the model, otherwise the model is of little use. Easier said than done though.
Anyway, the process should start by creating a simple but very accurate design of a small part of the domain. This inicial design should then be revisited, improved, incremented and re-factored in order to reflect a bigger set of the domain, in a way more suited to the actual implementation.
As in any activity, fast, easy and clear communication is essential for a good performance.
In a software development project, both domain experts and developers have their own language, with its own jargon and specificities. Both team member types are usually unaware of the others language, so it must be created a common language that everyone can understand without any ambiguity.
Continue reading “DDD.2 – Communication and the use of language”
Developers and Domain Experts collaborate, discussing the Domain Experts knowledge, distilling it into all, and only, the knowledge relevant to the project.
The objective is to end up with a model of what the application should do, how it should do it, and what the technical implementation should be.
@hgraca 