为什么领域建模?
来自于响应式设计者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翻译上进行调整,翻译不到之处请谅解。)