ドメイン駆動設計

Domain-driven design, DDD

継続的にドメインモデルを育て続ける

ドメイン("domain")「業務」

1.ソフトウェアの開発においては、まず、ドメインとドメインロジックに焦点を合わせる

2.複雑なドメインの設計はモデルをベースにする

1.「要素技術やアーキテクチャよりもドメインの方が重要だ」

2.「専門家が持つドメインモデルをベースにしてドメインを設計せよ」

モデルを構成する言葉は、会話やドキュメントなど、プロジェクト内のあらゆる場所で使われるべき

プロジェクト内にあまねく行き渡った言葉が、ユビキタス言語("Ubiquitous Language")

ドメイン駆動設計という仕事の流儀

http://www.slideshare.net/masuda220/ss-15655472

利用者のやりたいことを

興味を持つ

いつも話題にする

モデルに要約する

コードで実現する

ドメインモデル指向の設計パターン

・業務のトリガー「ドメインイベント」

ex.入会申し込み

-申し込み番号

-氏名

-連絡先

-申込日

↓起動

・業務手順の要約「ドメインサービス」

ex.受付()

{

検証()

記録()

通知()

}

↓移譲

・業務の知識「ドメインモデル」

ex.

会員とは?

入会とは?

申し込みとは?

受付とは?

ドメインモデル指向のフレームワーク

MVC

バリデータ

テンプレート エンジン

SQLマッピング

メッセージング

OX(Object/XML) マッピング

ドメインイベント駆動の実行環境

HTTPリクエスト(Web アプリ、Web API)

メッセージング(システム間連携)

電子メール(受信)

継続的にドメインモデルを

・育て続ける(Evolving)

-小さく生む

-フィードバックを反映しながら

・行き渡らせ続ける(Pervading)

-多くの関係者

-あらゆるタスク

-ドメイン以外のレイヤ

・結びつけ続ける(Binding)

-利用者の関心事とモデル

-実装コードとモデル

イテレーティブ(反復型)で発見的に

良い部品を探し続ける

・モデリング

・プログラミング

・リファクタリング

設計の原則

ギュッと集めて(High Cohesion)

サラッとつなぐ(Low Coupling)

→ドメインオブジェクトに適用する

業務の知識をギュッと集める(High Cohesion)

・パッケージ

・クラス

・メソッド

業務の概念ごとに独立させてサラッとつなぐ(Low Coupling)

・パッケージ

・クラス

ドメインモデルの設計(腕を磨く)

小さな部品

HowよりWhat

設計の本を読む

原則・パターンとの付き合い方

ドメイン駆動設計への道

小さく作る練習

実装のテクニック

実装の原則

設計のスタイル

UML

アジャイル

ドメインの理解/言葉の力/モデル駆動

小さな部品

部品(業務の基本用語)の粒度

日付 時分

翌営業日 休前日

月末 月初 四半期 半期 年度

期間

金額

単価

数量

消費税

端数処理

数量割引

管理番号

登録番号

取引先コード

シリアル番号

業務で必要なデータとロジック(知識、ルール)を凝集(カプセル化)する。

ドメインオブジェクト

小さく作る

クラス 50行まで

メソッド 3行まで

パッケージ 10ファイルまで

3行メソッド

nextStage()

{

ready();

set();

go();

}

小さく作る練習課題

  1. ひとつのメソッドは1段階まで
  2. else句を使わない
  3. すべてのプリミティブ、文字型をラッピング
  4. ファーストクラスコレクションを使う
  5. 1行につき、ドットはひとつ
  6. 名前は省略しない
  7. クラス50行、パッケージ10ファイルまで
  8. インスタンス変数は2つまで
  9. getter/setterを使わない

小さな部品 実践の小技

汎用部品より目的特化部品

if文を減らす・隠す

for文を減らす・隠す

stterを使わない

getterを使わない

HowよりWhat

方法(How)を記述 → 用語(What)をクラスで表現

本を読み いろいろな設計の考え方に触れる

小説じゃないのだから面白いわけがない

知らないことが書いてあるのだから、一読でわかるわけがない

何度も読み直す、 全体 部分

実際に作って覚える

仕事を楽しく

喜んでもらう

自分が成長する

面白いことをやる