<< ドメインの関心事 それ以外の関心事 | main | Smart UI が優れている? >>

ドメインを分離しつづける

前の記事の、Layered Architecture で、Isolating Domain (ドメイン層の分離)の続き。

ドメインのロジック、ビジネスの知識、ルール、決めごとは、書くことができる場所は、たくさんある。

UI層


velocity のテンプレートは、if 文、foreach 文が使えるので、ここに、ビジネスロジックはいくらでも書くことができる。

MVCのコントローラにあたる箇所だったら、ドメインのロジックだろうが、データアクセスや通信のロジックだろうが、なんでも書けちゃう。

インフラ層


技術的な実装手段、処理手順は、全部ここに押し込める。

で、技術的な手段といっしょに、ドメインロジックの一部も、この中に埋もれさせることも簡単。

例えば、データベースのマスターや、残高テーブルと、新規受注情報との突合せや、整合性維持を、データベースアクセス手順の中に、混ぜてしまうことはよくあるケース。

しかも、「○○テーブルの件数がゼロ件だったら」というように、ビジネスのロジックよりは、データ処理手続きの形式で表現する、(アンチ)パターン。

このデータアクセスロジックに、業務の言葉のメソッド名がついているなら、良いのですけどねえ。

現在進行形 isolating


エバンスは、Domain-Driven Design(DDD) の4章のタイトルを、Isolating Domain にしている。
isolate を現在進行形にしているのは、ドメイン駆動設計のポイントだと思う。

現在進行形は、別の言い方をすると、「まだ終わっていない」「継続中」であることを表す。

Isolating Domain とは、継続的に ドメインを分離しつづける、ということ。

ソフトウェアの開発の過程で、ドメインの知識、ルール、決め事を、繰り返し、他の関心事から分離を続ける。

ドメイン層以外に散在しているドメインの知識を見つけて、ドメイン層のクラスに移動する。

レイヤアーキテクチャを採用して、フレームワークを活用しても、ドメイン知識が、別の層にまぎれ込むことも多い。

それを日々、発見し、分離し、整理を続けることが、ドメイン駆動設計の良い習慣として実践することが大切。

コメント
コメントする









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