模型驱动的软件开发。
据我了解,它提高了设计的抽象级别,以更好地反映软件将尝试运行的领域。一句话就可以说很多。
领域专家(客户)和开发人员之间的沟通对于使这种方法发挥作用至关重要。我想知道的是,是否有工具套件或一组最佳实践有助于 MDSD 的初始推进?一旦领域被充实,如何将该模型映射到 ORM(或其他)?
我只是潜入 MDSD 和 DSL 领域,因此任何建设性的想法或评论都会受到重视。
模型驱动的软件开发。
据我了解,它提高了设计的抽象级别,以更好地反映软件将尝试运行的领域。一句话就可以说很多。
领域专家(客户)和开发人员之间的沟通对于使这种方法发挥作用至关重要。我想知道的是,是否有工具套件或一组最佳实践有助于 MDSD 的初始推进?一旦领域被充实,如何将该模型映射到 ORM(或其他)?
我只是潜入 MDSD 和 DSL 领域,因此任何建设性的想法或评论都会受到重视。
如果您在 .net 中编程,您应该阅读 Jimmy Nielsson 的“应用领域驱动设计和模式”。他还有一个关于 ORM (NHibernate)、SOA 和依赖注入的部分。
无论如何,您应该看看 Eric Evans 的“领域驱动设计”。这是一本经典之作,您可以在其中找到有关领域驱动设计模式和最佳实践的宝贵信息
如果您在 Microsoft 平台上进行开发,您可能还想看看 Oslo。这里有一个很好的概述: http ://www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx
这是来自 Chris Sells 的大量链接: http ://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=2197
我还没有准备好将领域驱动设计与模型驱动开发等同起来。
您可能还想查看模型驱动架构(OMG MDA)的观点,尽管您自己的滚动可能并不多。
模型驱动中的一个大问题与从模型中派生实现的专业知识的来源以及维护(和调试)发生的级别有关。我对可用书籍的测试将是它们如何使管道易于理解,以及人们如何理解从建模到部署再返回的路径。
免责声明:我是业务应用程序的开发人员。以下观点肯定是由我在企业 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
我认为这不能再简化了。此外,任何带有框和线的图形表示都不会简化,也不会提供更多便利(考虑布局、重构、搜索、差异......)。
MDD 可以非常复杂或相对简单。
如果您想将各种模型(例如在 UML 中)自动转换为代码并进行往返工程等等,您可以获得一些非常漂亮的工具。
或者
您可以使用单向(模型到代码)转换来或多或少地手动绘制模型和构建代码。
首先构建模型的想法是公认的最佳实践。它通常被称为“设计”。当人们将设计与规范混为一谈时,就会出现问题。将要构建的模型不是编程规范。它是一种抽象,可用于评估正确性、定义测试用例、编写规范等。
您不必对所有内容进行建模。您可以通过拥有一个独立于任何特定实现的数据模型来启动 MDD。
您使用 UML 绘制模型。
您将 UML 转换为类定义。
您使用 ORM 层(或 ODBMS)将模型映射到某种存储。
你不需要更多。您需要做的是在解决太多其他问题之前专注于让模型正确。
这些问题通常来自软件开发过程中发生的各种过早优化。RDBMS 物理设计的早期飞跃。早期进入网页设计并使用它来驱动数据模型。早期飞跃到定义服务器架构和分配存储。
您应该阅读 Markus Voelter 的这篇关于 MDSD 最佳实践的优秀论文:http: //www.jot.fm/issues/issue_2009_09/column6.pdf
关于 MDSD/DSL 选项,EMF 生态系统 ( https://www.eclipse.org/modeling/emf/ ) 提供了许多有用的构建块:
减少工具投资的一个有趣的选择也可以是使用可扩展的 UML 建模器,并在重用的建模器之上定义您自己的 UML 配置文件和自定义工具(如果您的 UML 建模器基于 UML2,前面的列表仍然足够/EMF 实施)。