虽然以上大部分观点我都不反对,但值得进一步探讨。
DDD 中最重要的概念是专注于问题域。将技术热情放到一边,主要集中于建模解决你所面临的问题。因此,将ajax、ORM、数据库、框架等技术放到后台,而是确保首先拥有一个完整、准确的问题模型。(当然还需要架构组件-但它们明确是为模型服务)。DDD 将这称为“普适语言”- 用领域专家和开发人员都能理解的术语表达的模型。在该模型中,类名、方法名称等来自于问题域。
DDD 并不规定/如何 捕获这个模型,虽然该书暗示使用面向对象语言来实现。
MDA 分享了以模型化问题域为首要任务(PIM,平台无关模型)的相同观念。与 DDD 不同的是,它推荐使用 UML 来创建该模型。但意图是相同的:了解问题域,并避免以(软件)架构问题影响其。
MDA 的 PSM(平台特定模型)有点类似于应用 DDD 中的架构模式(例如,聚合、仓储等)。再次强调-虽然细节不同-但两者的目标都是解决将“纯”问题域模型转换为完整软件系统的问题。
因此,总结一下,我认为它们在两个方面相似:
希望有所帮助。
Domain-Driven Design(DDD)和Model Driven Architecture(MDA)的根源都是模型驱动工程(MDE),也被称为模型驱动软件开发(MDSD),如果仅限于软件开发领域。参见维基百科:http://en.wikipedia.org/wiki/Model-driven_development
所有归属于MDE范畴的方法都有一个共同点:模型。这个模型如何具体实现取决于特定的MDE类型。
MDA被认为过于复杂。DDD被一些人认为过于抽象。我个人最喜欢的MDE实现是DSM和ABSE(未在维基百科文章中列出)。
DDD是从商业角度接近软件解决方案,旨在尽可能地使设计更贴近现实世界。这更像是一种艺术而非工程。
MDA解决了不同的问题集。更多详情请参见:http://xml.coverpages.org/OMG-MDAFAQfinal1.pdf
每种基于X的方法都有助于在问题解决活动中提供特定方面和表示的价值。从我的角度来看,主要的区别是DDD是一种设计技术,而MDA是一种基础设施,在工程界希望将其用于现实世界产业时需要它。
DDD中的Domain术语具有"isA"关系,与"Problem Domain"经常看起来相同。DDD重视领域专业知识,决策取决于我们了解问题的程度以及如何从初始状态到获胜状态选择正确的路径。在最终的设计规范书写之前,将会进行大量的问题研究。通过查看DDD的三个主要原则,我将DDD与我现在年龄熟悉的事物进行了映射(a)专注于核心领域(DDD和MVP在焦点设置上似乎是相同的),(b) 在创造性协作中探索模型(这是基于模型的工程),其中两位贡献者包括领域专家-设计师和专业软件开发人员。(c) 在明确的边界上使用普遍语言进行交流(使用领域特定语言进行沟通,并开发与问题领域相关的工件)
通过观察MDA和相关标准的开发协作,可以看出这是一种应用模型驱动工程的基础设施。这是软件行业在支持使用模型描述软件系统的方式方面的进化,并展示了我们如何组织CIM/PIM/PSM模型和工件。许多强大的建模操作和工具,例如模型转换、领域特定建模语言和自动化软件工程技术已经正式与MDA一起出现。