ScalaでDDDを実践する①


今回からScalaでDDDを実践するをテーマに書いていこうと思います。

具体的には、
今回:使用するフレームワークと選択した理由
2:LiftでmyBatisを使用する
3:LiftでBeanValidationを使用する
4:LiftでGoogleGuiceを使用する

と言った感じで、書いていこうかと思います。

そらぞれ採用するフレームワークのバージョンは以下の通りです。

Scala:2.8
Lift: 2.2
MyBatis:3.×
GoogleGuice:2.×
HibernateValidation:4.×

他の環境
SBT: 0.7
IntelliJ: 10

なぜこれらのフレームワークを採用するにいたったか?

まずScalaですが、ScalaはDDDを実践するうえで最適な言語だと思っています。

ScalaでDDDを実装する方法は、私が密かに尊敬しているこの方のブログを読んでいただくと理解できると思います。

ScalaでDDDをはじめてみよう

コードが驚くほど少なくなるだけでなく、valやcaseクラスやOptionなどJavaにはない言語仕様はとても便利です。

特にvalだけでイミュータブルにできる点やcaseクラスにすることで簡単にValueObjectができてしまうなどDDDを実践するに適した言語だと思います。

また、ScalaのWebフレームワークとして、Liftは最も有名なフレームワークだと思います。Liftは関数型言語であるScalaの言語仕様をフルに活かしたフルスタックのフレームワークです。

現在のLiftはデザイナーフレンドリーと言われ、htmlにソースが混じることがなかったり、単なるコントローラーではなく、スペニットを使用する点などがお気に入りです。AjaxやCometも簡単にできるのも魅力です。

しかし、LiftのModelはMapperと言われるO-Rフレームワークを採用している点がDDDを実践するうえで不満な点です。

MapperはいわゆるActiveRecordパターンを採用していて、ModelとDBのテーブルが1対1になります。

DDDでは当然リッチなDomainを構築するするのが前提であるため、このままModelを使用する場合は、DXOに変換して使用する必要があるでしょう。

せめて、テーブルの1フィールドを現す内部objectが外に出せればいいのにと思うのですが…

そこで今回はMapperを完全に捨ててO-RフレームワークにMyBatisを選択しました。

MyBatisはJavaのO-Rフレームワークですが、Scalaでも使用することができます。

MyBatisがScalaにぴったりだと思った理由はまず、オブジェクトの生成にコンストラクタが使用できる点です。

私の知っている他のフレームワークは基本SetterプロパティとDBのテーブルのフィールドをマッピングする為、valを使用することができませんでした。もちろん、Valueオブジェクトも実装できません。

フレームワークのためにSetterを用意してプロジェクト内部のルールとしてSetterを使用しないようにするとかしかありませんでした。

しかし、MyBatisはコンストラクタからオブジェクトを生成できるためほぼきれいなValueオブジェクトを作成できます。

caseクラスも問題ありません。

ほぼと書いたのは少しだけ制限があるからですがこの点は改めて書きたいと思います。しかし、Setterを書かなければならないなどの制限はありません。

さてMyBatisを採用すると困る点が一つあります。それはLiftのValidationの機能が使用できない点です。LiftのValidatioはMapperに依存しています。

なので、Mapperを使用しない今回はやはりJavaのBeanValidationを使用することにしました。

GoogleGuiceについては、MyBatisと連携できる事から選択しました。

やはりトランザクション処理を考慮する上でDI機能がないのはかなり苦しいです。

Springでもよかったのですがなんとなく内部DSLぽくできるのが(Mapperを捨てといてなんですが)選択の理由です。

次回はLiftとMyBatisを連携させて見たいと思います。

1件のコメント

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です