importance of object model in domain driven design

Our team is fairly new to domain driven design. We have a new project that just moved from design phase into coding phase. In the design phase, some team members created UML design m开发者_JAVA技巧odels in Visio, while others just started coding. Also, with the pressures of build releases, many of our models are becoming out of date quickly.

Is it important to keep the object models up to date? Is it important to have them for all/most sub-systems?

---

The best documentation that you have for your code (and models) is the code and database schema. Developing models outside the code can have some value in understanding the problem, but as you've discovered eventually these become a liability. If you are going to use them at all, you need to invest time in keeping them up-to-date. An agile philosophy would say to only invest as much time in maintaining these as you get value from them. Generally, that isn't much since the code is the ultimate authority anyway. If you have regulatory requirements, it might be a different case, but I would typically discard the model once it has been translated into code and regenerate the model as needed directly from the code/schema if you need a document to describe it.

---

I guess the answer is "it depends", no?

If the project is small, changing at a rapid pace, etc etc, the ROI of models is probably pretty bad, and in the end all that matters is the working code.

On the other hand, for multi-year multi-phase projects with a high degree of ceremony, a changing development team, etc etc, you'll have great benefit from some sort of documentation. The object models can be one such documentation.

There is no silver bullet after all, so, depending on which end of the scale your project lies, you may find the models to be very valuable or just costly to maintain.

---

The objective of having any type of documentation is helping the development, not stopping it. The developers know atm how the model is, and the main differences between what's in the code and what's documented.

But, you should be aware that you would have no material (other than the code itself) to show say, to a new-hire in the team, and it would cost some time to teach the new guy.

So it's a matter of deciding what is most efficient. If keeping the model obsolete makes the team faster, don't update the models. If updating the model will somewhat improve development, you should do it (no matter how boring)

---

Any documentation below the User Story Level is directly related to implementation details and thus to volatile facts (Why vs. How). It (the how, the models) should therefore not be maintained manually but instead generated when needed for the sole sake of developer communication improvement.

Documentation is great when it is maintained at all times. If you cannot guarantee that, go for source code documentation (and maintain it as you change the code) and generate as much UML from your code as you need, when you need it.

Then throw the generated documentation away again. It's only there to help you to better communicate with developers. It has no further value than that.

Just had it today: A developer approached me with a nice Visio diagram, printed out on paper, looking really nice. I opened up the IDE and showed him that the source code stated something slightly different from the documentation he held in hands. Took me some time to make it clear that code wins over documentation. Always.