为什么领域建模?

13-03-02 banq
来自于响应式设计者The Responsible Designer的一篇博文:为什么领域建模?Why Domain Modeling?

文章大意如下:

(我们知道一个软件的产生经过如下大概过程:

1.需求分析 2.软件设计 3.程序开发 4.测试 5。交付)

面向对象分析和面向对象设计两个阶段(其中1和2)之间一直存在距离(如书籍Object Oriented Analysis (2nd Edition) (Yourdon Press Computing Series) [Hardcover]):

需求分析时,你产生了一系列的任务描述和模型的对象,其中包括领域概念的陈述,并表明如何将这些对象交互来完成一些工作。 但你不能直接实现这些对象。

在面向对象的设计阶段中,你要完善之前分析模型,考虑到实施和技术的限制。 只有这样,设计完成后,才能落实到代码编程写程序。

也就是说,在分析或设计过程中产生的任何模型都需要大量的完善,才能根据其写程序。

我们很多人模糊了分析和设计编程之间界限。 在实践中,我们的工作往往是完全不同的迭代周期推动的。 我们可以分析问题,迅速勾勒出一些设计理念,然后实施。 我们可能会使用CRC卡,我们的对象模型可能会被我们将丢弃。

有时,分析问题和围绕问题设计实施的解决方案之间的差距并不显着。 有时,不同的人做了分析,而其他人进行设计和编程,但,开发人员能够多次做所有这些活动。

我们很少看到有人出具详细的对象的分析和设计模型。 良好的对象设计被程序认为是太困难,并没有时间。直接进入编码,结果丧失了良好的设计。

不管队伍是否实现敏捷开发,缺乏模型是很常见的,最常见的做法是有很详细的ER模型, 他们不漏掉任何细节,很难找到重点(没有显隐 没有主次)。

如果你的软件是复杂的,需求又瞬息万变,战略上你又没有做任何的领域建模,你可能会错过真正重要的东西。 如果您的软件是复杂的话,你可以大大受益于域建模。

如果你挖掘出域模型,您能形成在需求问题域与您的代码之间深刻的一致的共同理解。 你的任务不是仅仅提供软件可以运行的功能,而是嵌入到这些运行功能中的有关业务领域的解决方案知识。

代码中将使用对象表达业务领域的概念。 你会挑剔类和方法名称,使他们准确地反映了业务领域的概念。 您将有可以持续进行讨论的领域专家,共同探讨和完善对业务领域的理解。

一路上,你可以勾画和修改的域模型。 你会努力地维护以及加强明确业务概念和代码之间的连接。 当你重构你的设计,你能获得更深入的了解,你不会忘记那些反映业务领域的代码。

如果开发人员和领域专家之间进行更密切的合作,可以形成一个强大的力量。

(banq注:因时间有限,直接在google翻译上进行调整,翻译不到之处请谅解。)

         

3
flyzb
2013-03-02 17:45
业务分析重要,而业务设计也非常重要。对于企业而言,往往业务架构建模的过程要更复杂一些,比如CBM或者TOGAF技术。

在我看来,DDD中的领域建模更适合模块内部的建模。

banq
2013-03-04 14:00
2013-03-02 17:45 "@flyzb

"的内容

业务分析重要,而业务设计也非常重要 ...

分析和设计都重要,所以,他们经常不能很好衔接,分析的重点是盯需求,设计的重点是盯实现包括存储 分布式等等,就如同夫妻两个,心里有自己的想法,所以,经常吵架合不来。

DDD则是打通了这两种隔阂:

店铺的案例,这个案例很典型地将分析和设计使用DDD的值对象进行了统一协调,考虑到了需求,也考虑到分布式系统实现。落实到具体语言,Java可以使用final,Erlang或Scala直接利用其语言的不变性实现值对象。

[该贴被banq于2013-03-04 14:04修改过]

clonalman
2013-03-04 14:08
2013-03-04 14:00 "@banq

"的内容

设计的重点是盯实现包括存储 分布式等等 ...

这是架构方面的设计,不是领域设计!

领域设计的关键是对领域分析的进一步抽象!

banq
2013-03-04 14:26
2013-03-04 14:08 "@clonalman

"的内容

这是架构方面的设计,不是领域设计 ...

哈哈,这个你可以查查Eric Evans“DDD”书籍,分布式等架构设计都是DDD应该考虑的。也只有这样,代码才能直接实现,当初我也很惊讶,现在觉得DDD的魅力也就在这里。

猜你喜欢
2Go 1 2 下一页