<< 実践 ソフトウェア・アーキテクチャ : アリモノを活用する | main | 実践 ソフトウェア・アーキテクチャ : パッケージに凝集する >>

実践 ソフトウェア・アーキテクチャ : パーティショニング

レイヤ構造にして、レイヤごとに関心を分離できた。
実際のアプリケーションだと、横の分割だけでは不十分。

それぞれのレイヤごとに大量のクラス、ファイルを作ることになる。ひとつのレイヤ内で、さらに関心を分離して整理をして、理解しやすく、変更を容易にする。

具体的には、物理的にはファイル構成とディレクトリ構成。Java のクラスに限れば、パッケージ構成ですね。

RUP では「パーティショニング」という用語(概念)で、この関心の分離を説明していた。

どういう視点で分離するのかは、私たちも正直、試行錯誤です。
上のほうのレイヤ ( UI/Web層 、アプリケーション層 ) は、アクターとユースケースのパッケージ設計を使うようにしています。

ドメイン層は、主要なドメインクラスは、だいたい集約のルートになるので、その集約関係の単位でモジュール化する。
モジュールをまたがるようなクラスや、共通コンポーネントみたいなものは、モジュール化(グルーピング)の単位やパッケージ名が悩ましいことが多い。

下のデータアクセス層は、DBアクセスについては、ドメイン層のモジュール化に近い。
その他のデータアクセス処理は、mail とか file とか message とかのシステム機能の単位になる。

分割の単位

「論理的に意味がある単位」といっても、わからないので、単純なルールを作った。

・要素が7個超えたら、分割検討サイン
・要素が10個超えたら、注意警報
・要素が20個超えたら、レッドカード

という感じ。人間が一度に考えられる要素として「最大7」というのは、いつも意識するようにしている。

現実には、いろいろ議論がでてくるケースもあるけど、まず「分割ありき」という価値感を徹底することが大切だと思っている。
放置すると、すぐに大きな一枚岩、エアーズロックパッケージを作っちゃうので。

名前

パッケージの名前をつけるのも結構悩ましい。

上の層は、ユースケースモデリングとドメインモデリングのパッケージ図(構造と名前)を基本にする。

下の層は、詳細は、フレームワークにまかせている部分が多い。フレームワークと強く関連する場所は、フレームワークや Java の API パッケージの名前も参照にするようにしている。 Java のパッケージ名は、それほど良い名前とも思えないので、Spring のパッケージ名のほうを重視している。

放置すると、util とか io とか意味があいまいな名前がはびこるので、もっと、説明的な名前をつけるように指導している。

また、インタフェースと実装クラスとか、実装方式の視点でパッケージ化したがる開発者も多い。 下のレイヤでも、ドメインモデルの構造に関連するところは、可能な限り、ドメインモデルの構造と名前を持ち込ませるようにしている。

パーティショニング(縦の分割)は、アクター、ユースケース、ドメインが、全体構造を決める。
技術方式や技術的な特性により構造を決めるのでない、という点を何度も話すんだけど、なかなか伝わらない。

レイヤ分割(横の分割)は、技術方式の特性で関心を分離しているので、比較的、すんなり聞いてくれるんですけどね。

開発者に「ドメイン駆動」を浸透させるのは、なかなかたいへんです。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
 123456
78910111213
14151617181920
21222324252627
28293031   
<< May 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM