关于领域模型

superatao

杭州李云 发表于 2012-1-6 12:34
这个图很让人晕的。首先，我将图中的“采购申请”和“申请名细”当作是名词。以申请明细为例，如果其中可 ...

其实是这样的：“创建明细”的含义其实是指针对“申请明细”这个实体对象而言，insert一条新的明细记录。我原来把“申请明细”的CRUD操作放在该实体对象本身的操作中声明是考虑所谓高内聚低耦合的因素，但后来张恂老师上面已经指出——主信息和明细项信息是一种高聚合的关系，因此明细项的CRUD操作应该声明在主项信息里面，由主项信息作为容器去管理明细对象的生命周期。

杭州李云

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

这一模型就没有前面我所指出的问题。你对于高内聚低耦合的理解值得商榷，“铁锤自己会钉钉子”对，还是“人用铁锤钉钉子”对？

superatao

杭州李云 发表于 2012-1-6 12:43
这一模型就没有前面我所指出的问题。你对于高内聚低耦合的理解值得商榷，“铁锤自己会钉钉子”对，还是“ ...

是的，小弟对建模的通盘思路还是需要不断学习的，呵呵。

其实我最初的看法是：领域模型只是针对问题域而抽象出的分析类。而持久层的实体模型是在领域模型的基础上，针对问题域而提出的解决方案，即：设计类
最近在做一些事情，由于大家各自发表自己的看法，你一言我一语，着实把我搞得晕了（本来就不是很清楚的），确实已经不知道领域模型应该是什么样的，设计模型又该是什么样的，又该如何通过分析类进一步地提取出我们的设计类。
在这里我还是学习了不少的。

张恂

superatao 发表于 2012-1-5 16:46
张恂老师用“容器”和“主信息与明细信息的强聚合关系”解释得太通俗易懂了，我怎么就发现之前没有人给我 ...

>>对于采购申请主信息自身的CRUD操作，您觉得是否要定义在其实体类本身的操作中呢？还是剥离出来，放到逻辑层的类里面

采购申请还有哪些相关的类？要看它们之间的关系而定。

我估计“采购申请”的 CRUD 操作也需要由其他类来负责，比如某个“采购管理”类。

superatao

张恂 发表于 2012-1-6 14:15
>>对于采购申请主信息自身的CRUD操作，您觉得是否要定义在其实体类本身的操作中呢？还是剥离出来，放到逻 ...

其实这个问题也是一直不能明确哪种方式更加优化，因为也看到过充血模型、失血模型、贫血模型等等一些设计方式的优缺点，但综合比较下来，到底哪种方式更优，着实搞不透啊。

张恂

superatao 发表于 2012-1-9 12:13
其实这个问题也是一直不能明确哪种方式更加优化，因为也看到过充血模型、失血模型、贫血模型等等一些设计 ...

呵呵，这又是一个有意思的话题了，总的来说要根据具体 Context 权衡而定，下次有空再深入讨论。

你司现在的主要问题是缺业务建模和业务领域模型吧？

superatao

张恂 发表于 2012-1-9 15:54
呵呵，这又是一个有意思的话题了，总的来说要根据具体 Context 权衡而定，下次有空再深入讨论。

你司现 ...

什么都缺啊，呵呵，一切从头开始。
所以才会问业务建模过程中的领域模型。因为我觉得领域建模应该是第一步，第一步走好了，才会去做针对应用场景的应用模型，领域模型应该是比较固定的，而应用模型应该是可变的。不知道对不对。

张恂

superatao 发表于 2012-1-11 15:43
什么都缺啊，呵呵，一切从头开始。
所以才会问业务建模过程中的领域模型。因为我觉得领域建模应该是第一 ...

对！

业务领域模型通常比应用模型更稳定，有较大的重用价值，而且里面往往隐藏着很多业务规则、业务需求，没理清楚就会影响后续的软件需求分析和开发。

所以，对于企业信息系统开发，业务建模是非常重要的，业务流程模型和业务领域模型（动静结合）都值得投入好好分析。