Question

模型驱动的软件开发。

据我所知，它提高了设计的抽象级别，以更好地反映软件试图运行的域。这可以用一句话来说。

领域专家（客户）与开发人员之间的沟通对于使这种方法有效至关重要。我想知道的是，是否有一套工具套件或一套最佳实践有助于MDSD的最初推动力？一旦域充实了将该模型映射到ORM（或其他）的内容呢？

我只是潜入MDSD和DSL的领域，因此任何建设性的想法或评论都会受到关注。

Answer 1

如果您使用.net进行编程，则应阅读Jimmy Nielsson撰写的“应用领域驱动设计和模式”。他还有一节关于ORM（NHibernate），SOA和依赖注入。

无论如何，你应该看一下Eric Evans的“领域驱动设计”。这是一个经典，您可以在其中找到有关域驱动设计的模式和最佳实践的宝贵信息

Answer 2

如果您在Microsoft平台上进行开发，您可能还想查看Oslo。这里有一个很好的概述： http://www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx

我还没准备好将领域驱动设计与模型驱动开发等同起来。

您可能还想查看模型驱动架构（OMG MDA）的透视图，尽管可能不是很自行。

模型驱动中的一个大问题 - 任何事情都与专业知识的来源有关，它来自模型的实现以及维护（和调试）发生的级别。我对可用书籍的测试将是他们如何使管道易于理解，以及如何理解从建模到部署再返回的路径。

Answer 3

免责声明：我是业务应用程序的开发人员。以下观点肯定是由我在企业IT战略中的经验所塑造的。我知道，还有其他软件开发领域。特别是在工业和/或嵌入式系统开发中，世界可能看起来不同。

我认为MDSD与代码生成过于紧密相关。

代码生成仅在代码包含大量噪声和/或非常重复时才有用。换句话说，当你的代码不能主要关注基本的复杂性时，却会被意外的复杂性所污染。

在我看来，当前平台和框架的趋势正是为了消除意外的复杂性，让应用程序代码专注于基本的复杂性。

因此，这些新平台/框架从MDSD运动的风帆中汲取了很多风。

DSL（文本的）是另一种趋势，试图使人们专注于基本的复杂性。虽然DSL可以用作代码生成的源，但它们并不主要与代码生成相关联。 DSL（特别是内部DSL）基本上允许它在运行时被解释/执行。 [运行时代码生成介于两者之间]。

因此，即使经常与MDSD一起提及DSL，我认为它们实际上是MDSD的替代品。鉴于目前的炒作，他们也从MDSD运动中汲取了动力。

如果您已达到最终消除代码中的意外复杂性的目标（我知道这是虚构的），那么您已经达到了业务问题的文本模型。这无法进一步简化！

漂亮的盒子和图表不提供抽象级别的另一个简化或提升！它们可能有助于可视化，但即便如此也是值得怀疑的。图片并不总是表达复杂性的最佳表现形式！

此外，MDSD中涉及的工具的当前状态增加了另一级别的意外复杂性（想想：同步，差异/合并，重构......），这基本上无法实现简化的最终目标！

请看下面的ActiveRecord模型，作为我理论的一个例子：

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

我不认为这可以更简化。任何带有方框和线条的图形表示都不会简化，也不会提供更多便利（考虑布局，重构，搜索，差异......）。

Answer 4

MDD可能非常复杂或相对简单。

如果您想要从各种模型（例如UML）自动转换为代码并进行往返工程等等，您可以获得一些非常精美的工具。

或者

您可以使用单向（模型到代码）转换手工绘制模型并构建代码或多或少。

首先建立模型的想法是一种成熟的最佳实践。它通常被称为“设计”。当人们将设计与规范混为一谈时就会出现问题。将要构建的模型不是编程规范。它是一种抽象，可用于评估正确性，定义测试用例，编写规范等。

您无需为所有内容建模。您可以通过拥有数据模型来启动MDD - 独立于任何特定实现。

你不需要比这更多的东西。您需要做的是在解决太多其他问题之前专注于获取模型。

问题通常来自软件开发过程中发生的各种过早优化。早期进入RDBMS物理设计。早期进入网页设计并使用它来驱动数据模型。早期就是定义服务器架构和分配存储。

Answer 5

你应该阅读这篇关于MDSD最佳实践的优秀论文，来自Markus Voelter：http://www.jot.fm/issues/issue_2009_09/column6.pdf

关于MDSD / DSL选项，EMF生态系统（https://www.eclipse.org/modeling/emf/）提供了许多有用的构建块：

减少工具投资的一个有趣选择也可以是使用可扩展的UML建模器，并在重用的建模器之上定义您自己的UML配置文件和自定义工具（如果您的UML建模器基于以前的列表仍然适用关于UML2 / EMF实现）。