ドメイン駆動設計も随分と浸透してきたなぁと思うこのごろ。

でも、未だに動的型付き言語で頑張っている（弊社含め）現場も多く、今回は静的型付き言語について語ろうかと。

そもそもWebアプリの業界では単純にPHPやRuby、Pythonなど動的片付け言語で頑張る現場が圧倒的に多いかと思います。

しかし、ドメイン駆動設計を実践していくと、ある事実が襲ってきます。それはドメイン駆動設計は「型」の世界で成り立っているということ。

実践するにあたって、まず最初に乗り越える壁がレイヤアーキテクチャだったりするので、なかなか難しいと思いますが、本質的な部分は当然モデル。EntityであったりValueObjectであるわけです。

もちろん、動的型付きの言語でもモデルは書けます。弊社でもPython3の型ヒントを駆使してモデルを書いています。

ただ、モデルとは何かを考えてみていただきたい。

モデルとは、プロジェクトに携わる人々の頭のなかで構築された概念の集まりであり、ドメインについての洞察を反映した、用語と概念間の関係性からできている。(エリックエヴァンスのドメイン駆動設計第一部第二章コミュニケーションと言語の使い方より)

プロジェクトに携わる人々の頭のなかで構築された概念の集まり、すなわち、ソフトウェアが扱う領域のビジネスの知識というのが、モデルとして表現されているということです。

であるならば、当然ビジネスの変化によってモデルも変化するものと考えられると思います。
つまり、モデルは作って終わりではなく、リリース後もずっと変わっていくもの（変わらない＝ビジネスが停滞している=つまり変わり続ける）と言えます。

エヴァンス本の中身が難しいと先に「実践ドメイン駆動設計」を読む人も多いかと思いますが、
この本に欠けているのが、この部分の強調。
エヴァンス本には「第三部より深い洞察へ向かうリファクタリング」として丸々1部をかけて説明しています。

で、頻繁にモデルが変わるとなると、必要なのはリファクタリング。
特にクラス名の変更を多く使うことになります。

実際今自分が携わるプロジェクトも、新しいビジネスモデルを取り入れるにあたり、多くのクラスを変更する必要性が出てきているのですが、Pythonゆえに短時間での対応が難しいという問題に直面しています。
結局後回して、後日時間を取って丁寧に変更していこうという話になっています。。。

動的型付きの言語はここが弱いところ。
違う型が入ってきても動くし、該当のクラスを使用している箇所を探すのも一苦労です。

これが静的型付けであれば、ほぼ一発回答。最近の発達したIDEを使えば楽に変更が効きます。
最悪誤っていればコンパイルが通らないので、テストの実行や検証環境に上げて確認なんてする前に確認ができます。

そして、静的型付き言語はDIが使いやすいので、きれいにレイヤーアキテクチャを組むことも可能です。

WebアプリをPHPやRubyで入った方から見ると、敷居が高いと思われる静的型付け言語。
アプリサーバーとか必要ですしね。
しかし、最近はSpringBootに代表されるように、
アプリサーバーもセットになり、コマンド一発で実行環境が作れるフレームワークも多いです。

そして、最近はサーバーレスにも対応。AWSであれば、LambdaLayersなども登場し、フレームワークの重さも気にする必要がなくなっていますし、Lambdaの起動が遅い問題も解決されつつあります。

ぜひぜひ一度試してみてはいかがでしょう。