Domain Driven Design -ドメインを隔離する

レイヤー化アーキテクチャ

MVCを新人研修で聞いたくらいの知識しかなかった。

オブジェクト指向プログラムでは、UI、DB及びその他のコードがビジネスオブジェクトに書かれることがしばしばある。こういうことがおこるのは、短期的にみると、動くようにするには最も簡単な方法だからだ。

とりあえずそうやって書くのが一番わかり易い。

レイヤー化アーキテクチャは、経験と習慣を通じても最も直感的で共通見解があるものだ。

多層アーキテクチャ(たそうアーキテクチャ、英: Multitier architecture)とは、ソフトウェアアーキテクチャパターンである。 アプリケーションを複数の"層"に分け、それらを独立したモジュールとして開発・保守する。各層はインタフェースを定義しモジュール化されたソフトウェアであり、テクノロジーの進歩や要求の変化に合わせて各層を個別に置換できる。 各層をそれぞれ異なるプラットフォーム上で動かし、層ごとにプラットフォームの変更が可能である。 例えばクライアントのオペレーティングシステムをMicrosoft WindowsからUNIXに変更しても、他の層(ビジネス層、データベース層など)は変更しない。

アプリケーションが複雑になればなるほど、レイヤで分割して凝縮度を高めて下位層だけに依存するようにする。

ドメイン層

DDDにおいては最も重要な部分になる。アプリケーション層は薄く保って、概念、状態、ルール等を定義する。
技術的な部分はインフラに委託する。

レイヤの関連付けについて

上位レイヤから下位レイヤはいいが、その反対は基本はNGとする。それをやりたければ、コールバックやオブザーバを使う。

Smart UI ANTI PATTERN

DDDが過剰な場合もある。そういうUIだけでちょこっとできるような課題には、javaのような過剰なツールではなく、4GLみたいなものを使うべきだ。
Ruby On Railsとかかな。

Railsの基本理念は「同じことを繰り返さない」(DRY:Don't Repeat Yourself)と「設定より規約」(CoC:Convention over Configuration)である。
「同じことを繰り返さない」というのは、「定義などの作業は一回だけで済ませろ」との意味である[2]。「設定よりも規約」とは、「慎重に設計された規約(Convention)に従うことにより、設定(Configuration)を不要にする(あるいは軽減する)」ということである。Railsはフルスタックのフレームワークであり、コンポーネントの統合は手動での設定を必要とせず自動で規約に従い行われる。
例えば、Ruby on Railsに組み込みのORMライブラリであるActiveRecordでは、クラス定義においてデータベースから読み取るべき属性名等を指定する必要はない。ActiveRecordはRDBMSの表定義から自動的にその情報を取得する。したがって、プログラムとRDBMSの両方にそれを定義するというような冗長な作業を行う必要はない。