アンチパターン 利口なUI(スマートUI)
言うまでもなくアンチパターンとして紹介されていますが、実はこの章では、同時にドメイン駆動設計の難点や利口なUIとは別のアンチパターンも紹介されていました。
ドメイン駆動設計の難点
- 習得が難しい
- 各レイヤを管理するオーバーヘッド
- 専門家の手が必要
- 単純なプロジェクトでは効果が薄い
熟練したチームであればオーバーヘッドの時間は縮められます。
いつの間にか利口なUIになってることも
利口なUIとは、ビジネスロジックをユーザーインターフェイスに入れてしまうパターンです。
アンチパターンとして紹介されてますが、それがわかっていてもいつの間にか、ユーザーインターフェスにビジネスロジックが入ってしまっていることもあるかも。
テンプレートエンジンを使用しているときなど、htmlの中にifやforが入っていたらそこが危険ですね。ifの条件にビジネスロジックが入っていたり、forで繰り返すリストの取得方法が入っていたり・・・
利口なUIの利点
単純なアプリケーションであれば、すぐに作れて、有能でない開発者でも作れるし、プロトタイプから要件を引き出し変更することも可能です。また、RDBとの統合も機能して、保守する際も、特定の画面だけいじればいいので素早く作り替えが可能です。
利口なUIの末路
利口なUIで作成されたアプリケーションはそれ以上は成長できないです。
最初は作って終わりの予定であったアプリケーションでもその多く利用され続け、要件は追加され、複雑さを増していくことが多いと思います。
そういうアプリケーションは
- ビジネスルールは再利用できず、適用先にコピペすることになる(経験ありますねぇ)
- 複雑さを増したため、あとからドメイン駆動設計を適用しようとした場合は、リファクタリングではなく、完全に作り直しになる。(こちらも経験ありますねぇ)
なので、ドメイン駆動設計でアプリケーションを作成する場合は始めから適用しなければならないということです。
プロトタイプ用途ではどうか
先ほど、利口なUIであれば素早く作ったプロトタイプから要件を引き出し変更することも可能とありましたが、これもすぐに限界が来るはずですよね。
プロトタイプやイテレーションを利用して徐々に複雑にしていこうと思うのであれば、やはり初めからドメイン駆動設計を適用する必要があると思います。
絶対に捨てる前提であれば有りかもしれませんが、勇気が必要なのと、プロトタイプから要件は引き出せるが、プロトタイプを作っている間は対象のドメインについての学習はできません。その兼ね合いはとても難しそうですね。
他のアンチパターン トランザクションスクリプト
利口なUIとドメイン駆動設計の間のパターンとして、トランザクションスクリプトを上げています。
つまり、ユーザーインターフェイスとアプリケーションは分離するけど、ドメインモデルは作らないというパターンです。
このパターンであれば、まだ、将来的にドメイン駆動設計に移行できるかもしれないと言っています。
ドメイン駆動設計に移行するには、アーキテクチャがドメインに関するコードを分離していて、"凝集度が高いドメインの設計"と"システムの他の部分"が疎結合である必要があります。それができていればトランザクションスクリプトでも"おそらく"・・・ということです。