サブシステム

UMLの定義では、「サブシステムは要素のグループ化を指定し、そのうちの一部の要素が、ほかの要素によって提供される振る舞いの仕様を構成する」と述べられている。この定義は、実行時のシステムにおけるグループ化と設計モデルにおけるグループ化を明確には区別していない。設計モデルにおけるグループ化はパッケージを使ってモデリングするが、実行時のシステムにおけるグループ化は関連／リンクを使ってモデリングすべきである。これらを区別していないために、この定義は、設計時と実行時の要素のグループ化が同様のものであることを暗示してしまっているが、これは必ずしも正しいとはいえない。

サブシステムってインターフェースを実現するパッケージのことだと思っていたけど、これは設計時に限ってのことらしい。「実行時のシステムにおけるグループ化は関連／リンクを使ってモデリングすべき」というのでステートレスな業務ロジック層を思い浮かべてみた。

　より良い考えは、サブシステムのfacadeクラスをインスタンス化し、そのインスタンスをサブシステムのクライアントに引き渡すメカニズムを用意することである。クライアントがサブシステムの内部について何も知らなくても済むように、インスタンスを引き渡す前に、それをサブシステム・インターフェイスの型に型キャストする。これによって、すべてのクライアントがサブシステムの内部の実装から切り離されることになる。

DIコンテナのことに聞こえる。IBMもDIコンテナを推している？

サブシステムの再利用を妨げないために「ICustomer」の例でパラメータにインタフェースを持たせているけど、振る舞いを持たないDTOでも目的は果たせるかな？