发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA
1 2 3 下一页 Go 3

领域驱动设计的优点和挑战

                   
2014-10-09 10:43
赞助商链接



这是来自drdobbs的Dino Esposito文章。在领域驱动设计提出后这十年,DDD已经证明对于某些复杂项目是有效的,为实践提供了适当的指导。

大约十年前,Eric Evans提出新的软件开发方法:领域驱动设计(DDD),这是一本很受欢迎的书籍。

起初,DDD听起来像一个相当有前途的方法。对于一个复杂的项目开发人员来说非常诱人。在DDD中,一旦理解了软件需要解决的业务领域,那么你所要做的就是建立一个分层架构,业务逻辑被分成两个不同的模块,核心域逻辑(相对用例是不变的)和应用程序逻辑(用例)的实现。

DDD有其自身的分析部件(如通用语言,有界的上下文和上下文映射;它有一个战略组成部分方面用来严格支持相关软件架构和实现。流行的富领域模型(充血模型)只是许多可能的支持架构的其中之一。(一个基于充血领域模型的系统本质上并不比一个普通的CRUD系统更好,只要这两个系统满足需求。软件的复杂性主要源于基础业务的复杂性问题)。

DDD为理解错综复杂的业务领域提供了宝贵帮助。DDD提供的分析部分要好于其支持架构。DDD无处不在的语言提供一个方法来了解关键术语:名词、动词、副词——这些都是由业务专家使用。通过建立这样一个词汇,架构师和开发人员也可以理解它们。因为即使在同一家公司,语言会经常变化,使用相同的术语却意味着不同的东西或代表不同的聚合数据,这就造成沟通混乱。这种情况下形成一个最终系统的有界上下文,就像一个黑盒连接到系统的其余部分。上下文映射是连接上下文的映射图。每个环境都有自己的语言,使用一个独立的实现和接口与其他有界的上下文交互调用。整个系统就是由有界的上下文组成。DDD的最终目的是在有界的上下文中实现清晰而明确的收集需求。

DDD应对软件设计的复杂性不是作弊,。它将专注于问题域。然而,DDD却是很容易被做错,从而带来显著的成本。

普遍认为,虽然可以使用DDD带来明显的好处,但是却难以解释为什么需要实现这些好处。事实是,在过去的十年中,许多项目使用DDD有许多成功与失败。那些最终成功仍然经历了相当多的困难。为什么?

我的理解是,对DDD有一些误解,最重要的是,DDD往往减少到仅仅是建设项目中的一个领域模型。但也有一些其他的误解,比如将领域模型看成需要包含所有可能的行动,还有,将领域模型的构件(如通用语言)作为直接实现细节(抽象和具象不分)。

我叫他们为“误解”——从字面上,基于错误的观点或意见不正确的思考和理解。根据起点和上下文每个感知都可以是正确或错误。DDD的起点是它为设计服务的,然后才可能为落地实现细节的目的服务。所以,事实上,实现细节在哪里?

DDD有助于发现高层架构,发现软件需要复制的领域中的机制和动态。具体地说,它意味着一个好DDD分析会最小化减轻领域专家和软件架构师之间的误解,并且减少了后续昂贵的需求变化的数量。

通过分割复杂性领域到较小的上下文场景,DDD避免让项目架构师设计一个臃肿的对象模型,这个胖模型花费大量的无用时间在工作实现细节——部分原因是实体处理通常数量的增长超出了大小会议室的白板。(因为细节太多,超过会议讨论的范围,具体实现时会加入到对象模型中造成臃肿庞大的一个大对象,DDD目标是在会议讨论时将这些细节提前设计切分为上下文场景)

DDD针对特定类型的项目是一种有效的技术:复杂的项目通常有一个很大的问题域,需要与领域专家交流需求。使用一个模型直接落地为一个编程设计(一般来说,OO)实现,对于这些项目,这几乎是理想状态。然而。理解领域模型如何准确地映射到编程实现是至关重要的,这一步往往决定了项目的成败。


6
2014-10-09 23:05

2014-10-09 10:43 "@banq"的内容
理解领域模型如何准确地映射到编程实现是至关重要的,这一步往往决定了项目的成败 ...

呵呵,最近闲来无事,又来捧场。
这个帖子,一个让我思考的点,居然是‘副词’。。。
另外一个点,这个帖子说明了,领域分析专家,再也无法轻松的说只专注于分析问题域了,因为他分析设计出来的东东,很可能无法落地,哈哈,那就什么也不是了。。。看起来像废话,不过好在本着‘实践’的精神,那些指导方针都还是考虑了如何成功降落的问题

2014-10-11 08:06

2014-10-09 23:05 "@ericyang"的内容
这个帖子说明了,领域分析专家,再也无法轻松的说只专注于分析问题域了,因为他分析设计出来的东东,很可能无法落地 ...


领域分析专家有时是产品经理,对于一个复杂项目,如何让产品经理和架构师(技术负责人)统一交流语言,DDD提供了一种简单有效的方法,当产品经理说某个领域模型 在什么上下文发生什么事件动作时,技术人员应该明白那是怎么回事,如何实现。

该文一种观点认为贫血模型和充血模型在实现需求时区别不大,我个人不是很认同,贫血模型很显然走到臃肿模型的另外一个极端:

贫血模型(类似纯粹数据结构) -->充血模型 ---->臃肿模型

因为贫血模型的将一些业务职责割裂出去,比如放到服务之中,那么当维护拓展时,我们可能去修改服务,而服务应该是客户直接调用的接口,是连接前后端的节点,如果这个节点发生修改,会影响客户端代码,这是相当危险的。

其实虽然我们的业务逻辑有些变更,但是对客户服务接口可以不变,比如加油站的油价提高了,加油服务不会变,客户来了还是享受和以前一样的加油服务,将车开到加油机,指定油号加油。

后端系统中就简单两个模型:服务和实体,其实学问大了,通常Spring/JavaEE是将实体作为贫血模型使用,大量逻辑在服务中,服务的每个方法都很臃肿,这就是CRUD系统的现状。

2014-10-11 11:42

显著的优点是减少沟通成本,发现潜在需求,挑战方面,要象设计架构一样来设计领域逻辑,需要抽象、抽象、再抽象

2014-10-11 13:10

2014-10-11 08:06 "@banq"的内容
领域分析专家有时是产品经理 ...

所以有个兄弟说DDD难,必须要有丰富的程序开发,设计,架构经验,丰富的质量管理经验,丰富的产品管理经验,丰富的需求分析和客户沟通经验,当然,少不了还得是一个成功的项目经理人,,有点像几十年前对系统分析师的资格要求。比如,通用语言这一关,很多项目就铩羽在这一块。今早还碰到一例,我一个需求分析师和客户就是牛头不对马嘴的在谈变更,特别跨国项目,这个问题的影响就更显著了。

3Go 1 2 3 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com