工具(最佳实践？)对于模型驱动的开发？

Question

模型驱动的软件开发。

据我所知，它提高了设计的抽象级别，以更好地反映软件将尝试在其中运行的领域。仅用一句话就能说出这么多。

领域专家(客户)和开发人员之间的沟通对于此方法的工作至关重要。我想知道的是，是否有一个工具套件或一组最佳实践将有助于MDSD的初始推力？对域进行充实后，如何将该模型映射到ORM (或其他任何对象)？

我只是潜入MDSD和DSL的领域，所以任何有建设性的想法或意见都会得到重视。

Answer 1

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

这里有大量来自克里斯·赛尔斯的链接：http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=2197

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

您可能还想查看模型驱动的体系结构( OMG MDA)的透视图，尽管您自己的可能不是很多。

模型驱动中的一个大问题-任何事情都与从模型中派生实现的专业知识来自哪里以及在什么级别进行维护(和调试)有关。我对现有书籍的测试是，它们如何使管道变得可理解，以及人们如何能够很好地理解从建模到部署再回来的路径。

Answer 2

如果你正在用.net编程，你应该阅读Jimmy Nielsson的“应用领域驱动的设计和模式”。他还有一个关于对象关系映射(NHibernate)、面向服务的体系结构和依赖注入的章节。

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

Answer 3

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

我认为MDSD仍然与代码生成有太多的联系。

只有当您的代码包含大量噪声和/或非常重复时，代码生成才有用。换句话说，当你的代码不能主要关注本质的复杂性，而是被意外的复杂性污染的时候。

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

因此，这些新的平台/框架大大削弱了MDSD运动的势头。

DSL(文本化的)是另一种趋势，它试图使人们能够只关注基本的复杂性。虽然DSL可以用作代码生成的源代码，但它们并不主要与代码生成相关。DSL(尤其是内部DSL)基本上允许它在运行时被解释/执行。运行时代码生成介于两者之间。

因此，即使DSL经常与MDSD一起提及，我也认为它们确实是MDSD的替代方案。考虑到目前的炒作，他们也从MDSD运动中夺走了动力。

如果你已经达到了最终从你的代码中消除意外复杂性的目标(我知道这是虚构的)，那么你已经达到了你的业务问题的文本模型。这不能再简化了！

漂亮的方框和图表不提供抽象级别的另一种简化或提升！它们可能对可视化有好处，但即使是这样也是值得怀疑的。一张图片并不总是掌握复杂性的最佳表现！

此外，MDSD中涉及的工具的当前状态增加了另一个级别的意外复杂性(想想:同步、差异/合并、重构……)这基本上使简化的最终目标化为乌有！

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

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

我认为这不能再简单了。此外，任何带有方框和线条的图形表示都不会简化，也不会提供更多的便利(考虑布局、重构、搜索、差异...)。