比较以UML图进行领域建模和以绘制UI进行领域建模

昨天在和一个同事讨论新平台中我们是如何开始一个项目的时候，都同意要从业务建模开始。业务建模－Business Modeling 是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。这方面的工作可能包括了对业务流程建模，对业务组织建模，改进业务流程，领域建模等方面。但在讨论如何进行领域建模时，我们出现了分歧。我建议采用UML图的方式进行领域建模，而同事却提议按照金蝶EAS的做法，以绘制表单界面的方式进行领域建模。


确实，咋一看，以绘制表单界面方式进行领域建模有一个非常大的好处，就是在进行领域建模时，就能看到表单界面，能给人一种非常直观的感觉。但仔细一想，却发现这种方式的缺点。下面我就对这两种领域建模方式作一个比较。

1. 采用UML图进行领域建模，能够非常清晰的表现出整个系统中各个领域之间的关系（关联、包含、继承，1...1，1....n 等等）。
而采用绘制界面进行领域建模，则无法清晰的表达出这种关系。这对用户、架构师、开发者理解该企业的业务关系造成不利影响。
同时并不是所有的业务信息都会在界面上展现出来，反而是那些隐藏的属性体现了一些关键的业务信息。
2. 采用绘制界面进行领域建模时，架构师会将注意力集中在比较底层的实现细节，而很难将注意力集中在最具意义的业务关系上。这对深刻理解并挖掘用户需求也造成不利。[*]绘制界面领域建模能适应一些小的项目，但对集成现有系统来说，就无能为力了。

对于以绘制表单界面进行领域建模的优点，UML领域建模也能够实现。绘制好UML图后，就可以通过模板来生成相应的代码，包括了领域对象、服务接口、UI，以及所谓了Controller，这样也能实现快速开发的需求。同时这种实现方法对集成开发环境的要求并不很高，因为它可以不一定需要一个所见即所得的界面绘制工具。开发者在生成代码后，可以将其部署到内置的运行环境中去，立即就可以看到相应的界面效果。

上面是我的一些看法，大家一起讨论一下。

如果是两都非要取其一的话，我选择采用UML图。
不过如果你们有时间都画出来的话，不是更能表现业务模型吗？
业务建模的目的是什么？让人通过模型理解业务领域。
业务模型是业务的核心，UML图或者另一种文档方式只是业务模型的表现。只要两者不冲突，为什么不能共存呢？

請問領域建模是對應UML里面的哪種圖？謝謝

請問領域建模是對應UML里面的哪種圖？謝謝

其实只要能揭示业务模型，用什么形式表达都可以接受

界面建模可以迅速把握用户需求，用户看不到你底下的所谓架构，只能看到界面，界面将最大程度影响用户体验和反馈。

界面也是大多数user case的入口，可以通过顺序图发掘出潜在的对象和关系，衍生出UML上的结果。

做需求时，界面原型是很好的东西。