Sculptor的DDD风格的DSL

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;

            }
        }

    }
}

实际上，这个是类似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修改过]