最近看了看领域模型驱动这本书，只看了前面几章，但也深切的感受到了模型的重要性。通过与代码同步的模型，能够维护一个很好的知识共享的空间，包括设计者与程序员之间，客户与设计者之间
……
而且模型应该尽可能简单，让不同背景的人都能够很快学会，并都能对模型有所增益。
那么这个模型应该是什么样的？书我没有细看，只说说自己的体会。关于设计，很早就有数据驱动和对象驱动的提法。在
Without EJB
里，
Rod
也有讲：数据驱动或者说面向数据库设计更成熟，工具更多；而对象驱动更符合面向对象程序的特性，但由于掌握的人较少，风险较大。而通过模型驱动，我认为很大程度填补了
2
种方式的鸿沟，核心是模型，具体是对象模型还是数据模型并不重要，重要的是这个模型能够与需求、代码、数据库保持一致。
说到这里，顺便谈一谈我对文档的理解。我一直是
XP
的坚定支持者，甚至有点偏执。而由于文档不易阅读和沟通，且经常会出现与设计和代码的脱节，导致其可读性更差，所以我一向对文档不大感冒，更倾向于使用代码说话。但在目前的公司项目中，由于更多采用传统的软件过程，我也写了很多的文档，包括需求规格说明书、概要设计文档、详细设计文档等等。从对项目的帮助来看，文档作用并不太大，或者说是付出收益比太低，更多的是给客户写的，而不是给程序员写的。从程序员的需要来看，他关心的是每个实体的属性和关联，核心的接口、输入和输出，页面间的跳转和数据流，然后有一个统一的框架和编程模式。我的体会是：如果以文档为核心，很难描述清楚这些东西，且难以应对变化。
而通过以模型为核心（项目现在采用的
power designer
的概念模型为基础），辅以适当的描述，既能够加快大家对项目的认识（程序员是后面才加入），又能够节省一些写文档的时间，更早投入开发。
说到
power designer
，我也比较惭愧。用了好久，一直只是把它当成看数据库的工具。项目一开始就是从物理模型入手，结果举步维艰。后面从概念模型入手，就感受到了它的好处。使用概念模型，不用考虑太多关联表、外键什么的，而是从实体出发，然后确定相互间的关联，是一对一、一对多还是多对多。然后自动转成物理模型，并直接与相应的数据库挂钩。从这点上看与从对象设计出发真的非常相似。其实这也是合情合理的，正体现了这个世界的统一性吧（物理学界不也在搞什么统一场理论的证明吗）。
Power designer
也做了
conceptual model, physical model, object-oriented model
和
xml model
的自动转换，我现在还没全部摸熟。
openfans
则是从对象入手，并通过
hibernate
建立与数据库的联系，也体现了一定的方便灵活性。但比较糟糕的是，只有代码和配置文件，没有清晰的便于交流的模型，谁要想参与只能先去慢慢看代码。所以我先通过
together reverse
出来一个类图，然后适当加以文字进行说明。类图已经做好，但比较乱，还需要更多的图例加以说明。文字说明就是下一篇
blog
的工作了。也算是预告吧！