Sculptor的DDD风格的DSL

09-10-10 banq
         

Sculptor严格来说是一个代码生成工具,帮助那些基于模型驱动开发的团队快速开发项目。通过使用Sculptor,开发者可以专注于开发业务逻辑代码而忽略技术细节。开发者可以借助Domain-Driven Design(DDD),使用Sculptor特定的Domain Specific Language(DSL)编写用例,Sculptor通过解析DSL生成基于Spring和Hibernate/JPA架构的Java代码和配置信息。1.7版本还新增了对Google App Engine的支持。同时新增了一个maven archetype,用于快速生成基于Spring 3.0的RESTful项目。

Sculptor代码生成过程比较简单,主要是借助Maven生成项目结构,以及一些缺省的配置,然后让你在其特定配置

文件中输入其特定的DSL语言,这个DSL语言主要是根据DDD中对模型划分而来,主要有实体 值对象和服务 仓储等几个部分组成。

下面是其一个HelloWorld的DSL,这个DSL是由领域专家分析需求得出的,和我们前面讨论“另外一种DSL尝试:UML脚本”类似,不过这个DSL有DDD语境的约束。

Application Universe {
    basePackage=org.helloworld

    Module milkyway {
        Service PlanetService {
            String sayHello(String planetName);
            protected findByExample => PlanetRepository.findByExample;
        }

        Entity Planet {
            String name key;
            String message;

            Repository PlanetRepository {
                findByExample;

            }
        }

    }
}
<p>

这个应用中有一个模块milkyway银河系的应用,其中由一个实体Planet和一个服务PlanetService组成。在这个服务PlanetService中的方法findByExample依赖DDD中仓储PlanetRepository.findByExample实现。

实际上,这个是类似Java语言的简写,如果有过DDD编程经验的人,应该马上知道:Planet是一个普通类,而PlanetService是一个接口,PlanetRepository可以通过DI注入到PlanetService实现类中。

Sculptor就负责把上面DSL语言翻译生成Java代码,结果结构如下(这个结果和基于Jdon框架的案例结构类似):

其服务 仓储的调用顺序图如下:

我个人观点来看,Sculptor的DSL语法并不比Java语法精简多少,而且Java的类语法可以使用Eclipse等UML工具

直接映射出UML图,而Sculptor的DSL则是在UML和Java之间多了一层语法,你需要学习这些语法

Sculptor主要核心是其内部内置了DDD的元模型,如实体 服务 值对象,然后在使用时,你按照你的业务实体套上这些帽子,这样你的业务就置于Sculptor内在本身流程管理中,如果Sculptor这样框架内置了一些行业内基本流程和逻辑,那么这样套帽子做法才有价值,否则,就只是一个上面顺序图中服务调用仓储的流程固化,意义就不大了。

这也是我当初没有在Jdon框架强制引入DDD概念的一个考虑之处,你让基于你的框架应用戴个DDD帽子,除了好看,告诉别人我是DDD以外,并没有给使用者带来好处,而如果在框架中加入工作流等行业相关流程整合,这个帽子戴得就有价值了。

总体来说,作为一个通用的开发模式,基于动态脚本语言的DSL也许更具有普遍性,Sculptor的DSL可以适合一些专用行业领域,比如可以为进销存系统学习Sculptor定义一套DSL,这样只要简单定义一下自己领域的模型,一套强大通用又专用的进销存系统就能跑起来了。

开发HelloWord的全过程

[该贴被banq于2009-10-10 14:35修改过]

[该贴被banq于2009-10-10 14:36修改过]

         

bloodrate
2009-10-12 09:40

一直想理清楚DDD和DSL的关系,DSL在DDD中扮演的角色。。