关于领域模型

superatao

张恂 发表于 2011-12-30 11:52
>>也就是分析类和设计类的区别，如何由提取分析类，如何由分析类生成或形成系统的设计类。

推荐你读下 C ...

一直都听说这本书不错，但还没机会阅读，一定要买本读一读。

张恂

superatao 发表于 2011-12-30 13:34
而我个人又觉得，以上两种方式都不应该被称作为“领域模型”抽取，其实都是在从软件开发和实现的角度，去抽 ...

>>以上两种方式都不应该被称作为“领域模型”抽取，其实都是在从软件开发和实现的角度，去抽取持久层的实体类。真正的领域模型应该是客观世界对象的真实反映，再把它们进行建模。

对！这个真正的领域模型，就是我说的业务领域模型（BDM），其中的类都是业务实体类（Business Entity），属于问题域（Problem Domain），是领域建模的真正起点。通常这些类是没有（计算）方法/操作的。

之所以造成混淆，是因为你所说的是业务领域模型，是业务实体，是因；而他们说的是软件架构中的领域（设计）类，属于解决域（Solution Domain），是软件实体，是果。从问题域的领域类开始，导出解决域的领域类，这是一个更合理的跨界分析过程。

理论上，两者都可以简称为“领域模型”，如果不加区分说明，很容易造成鸡同鸭讲。

张恂

superatao 发表于 2011-12-30 13:18
我举个例子吧：拿一个采购系统为例，其中涉及到采购申请单、采购合同等。我在设计领域模型的时候总会从系统 ...

>>我在设计领域模型的时候总会从系统实现（也就是持久层）的角度出发去抽取“领域模型”

通常这个做法和习惯不好，相当于逆向工程。

业务建模、领域建模最好从业务需求描述和文档开始，尽量不要考虑软件实现。这样有可能做出更稳定、更优化的领域模型。

正确的顺序是：Problem Domain -> Solution Domain

张恂

superatao 发表于 2011-12-30 12:45
感谢张恂老师的解答，您的回复非常清晰。
站在不同层面来看这个问题，确实有时候会搞晕（应该说现在还是有 ...

呵呵，谢谢！

欢迎加入太极派！

superatao

感谢张恂大师高论。

张恂

呵呵，不用客气！

张恂

superatao 发表于 2011-12-30 13:22
但是又有人指出，我这样抽取是不合理的，领域模型不能够有“自己创建自己，自己更新自己”的所谓操作。所以 ...

>>主信息中的操作有“添加明细项、修改明细项、删除明细项”等操作。我个人总觉得不合适，因为这岂不是不符合高内聚低耦合的原则了，因为“采购申请”类跨类去操作了“申请明细”类。

这个模型他们说的对，“申请明细”对象的 CRUD 等操作应该由“采购申请”对象负责。

“采购申请”和“申请明细”是一种组成（强聚合）关系。

A 聚合了 B，或 A 是 B 的容器，这时由 A 来管理 B 对象的生命周期、访问和更新是很合理的，符合高内聚、低耦合原则。

不过这里，我们是在软件架构-设计（实现）类的层面上讨论领域模型，所以类、属性、操作名称最好不要用中文，建议用英文重新写。

中文名称在太极建模（UTM）中，通常用来表示业务领域模型和业务实体类，这样就可以避免混淆。

superatao

张恂 发表于 2012-1-4 16:48
>>主信息中的操作有“添加明细项、修改明细项、删除明细项”等操作。我个人总觉得不合适，因为这岂不是不 ...

张恂老师用“容器”和“主信息与明细信息的强聚合关系”解释得太通俗易懂了，我怎么就发现之前没有人给我这么讲解过呢，否则也不会搞得到现在都在困惑。呵呵。

另外，张恂大师，对于采购申请主信息自身的CRUD操作，您觉得是否要定义在其实体类本身的操作中呢？还是剥离出来，放到逻辑层的类里面，由逻辑层的类去调用持久层的DAO作数据保存？

杭州李云

superatao 发表于 2011-12-30 13:18
我举个例子吧：拿一个采购系统为例，其中涉及到采购申请单、采购合同等。我在设计领域模型的时候总会从系统 ...

这个图很让人晕的。首先，我将图中的“采购申请”和“申请名细”当作是名词。以申请明细为例，如果其中可以有“创建明细”这个动作，那到底是先有申请名细还是先有“创建明细”这个动作？建模的重点是要符合人的思维常识，我们的常识是通过“创建明细”这个动作可以获得“申请名细”，而这张图就没有符合这一常识。

杭州李云

张恂 发表于 2011-12-30 17:31
>>我在设计领域模型的时候总会从系统实现（也就是持久层）的角度出发去抽取“领域模型”

通常这个做法 ...

很认同这一观点。我们有时将因果给倒置了，等同于问题都没有分析好就去解决问题了，这种做法所获得的设计很容易概念不清。