1. DSLからのコードジェネレー
ションで楽々Play開発
芸者東京エンターテインメント株式会社
竹下 義晃

2. 自己紹介
東京大学 農学生命科学研究科 修士卒
竹下義晃
芸者東京エンターテインメントでScalaとC#を書い
ています。
隔週でやってるScala勉強会の会場を提供してい
ます。ぜひ来てください。
あと、９月開催のScalaMatsuriにも是非来てくださ
い。

3. 動機
同様なコードを書くのが面倒
同様＝コピペして、ちょこっと手直し

4. たとえば
● PlayのControllerとMethodを作って、だいたい
その名前に対応したURLをroutesに記述
● DBモデルクラスとテーブル定義
● APIでのやりとりのために、サーバー（Scala)と
クライアント（C#)で、ほぼ同じモデルクラスを作
る

5. つまり
● 汎用的に作られたFrameworkと、個々のプロ
ジェクトルールやビジネスルールとの差異を埋
める
● 異なる言語で同じようなコードを書く手間を減ら
す

6. 解決策
DSLを定義して、そこからコードジェネレーションを
行う

7. DSLとは
Domain Specific Languageの略
特定の分野に限定し、それに特化した言語
正規表現やSQLもDSLの一種。

8. DSL以外の選択肢
コードジェネレーションのベースとして使用されるも
の
1. ClassにAnnotation
2. XMLなどの既存のフォーマット
3. DBからのリバースエンジニアリング
4. UML
5. エクセル

9. DSLの長所と短所
長所
● プロジェクト特有の機能に対応できる
● 簡潔にかける
短所
● 新しく学習すべきことが増えてしまう
● ツールサポートがない(簡潔にかけるからツール
サポートいらない)

10. どれくらい強力か？
うまく言えないのでライブコーディングで確認してく
ださい。

11. Twitterクローンを作ってみる
https://github.com/takezoux2/dslgen-at-play-
meetup
● ログイン機能のみできている
● DSLからのコードジェネレーションは実装済み
● つぶやく機能を追加

12. 機能実装に必要なもの
● DBモデルクラス
● Repositoryクラス
● Serviceクラス
● Controllerクラス、メソッド
● Viewファイル
● View用モデルクラス
● routesファイル
● DBテーブル定義ファイル

13. コードジェネレーションのためのトリック
プロジェクトのコーディングルールをきっちり決める
● DBからの取得はIndexをはってあるフィールド
を条件にしてでしか取得してこない
● Controllerの名前とメソッドから、URLを決定で
きる

14. どうでした？
コードジェネレーションは非常に強力です。
● ロジックのみに集中してコード出来る
● 新しい機能の追加が早く＋確実＋フォーマット
が統一される
● プロジェクトのルールが変わらない範囲の仕様
変更ならば、非常に楽に修正できる
● プロジェクトのルールが変わっても、少しの修正
で全てを直せる

15. コードジェネレーションの欠点
● コードジェネレーションを作るためのコストがか
かる(今回のものぐらいで5時間程度かかりまし
た。)
-> フレームワーク化できたりするかな？
● 例外的なことに対応しにくい
-> 既存コードと生成コードをうまくマージする機能
を付けることでわりと解決します

16. 実プロジェクトでは
● マーカーを仕込むことで、ファイルの一部のみ
自動生成されたコードを埋め込めるようにして
いる
● クライアントと共有したいモデルクラスや定数も
生成
● デバッグ環境では、DBのテーブル更新も自動
化
● DBのマイグレーションファイルも生成

17. 参考文献
Code generation in action(Amazon)
エリック・エヴァンスのドメイン駆動設計(Amazon)