<< ドメイン駆動設計の基本テクニック : パッケージ | main | DDDの Entities パターンと Value Objects パターンを理解する >>

ドメイン駆動設計 :どこまで実践できている?

Domain-Driven Design(DDD)の5章は、

・関連
・クラス
・パッケージ

というクラスモデリングの基本テクニックの話し。

本で解説しているパターンは、

・Associations ( 関連の最小化の原則 )
・Entities パターン
・Value Objects パターン
・Services パターン
・Modules ( Packages ) パターン

の5つ。
ここ、2週間くらい、この日記でもいろいろ書いてきた。

5章のまとめ的な意味で、自分たちの実践状況の振り返り。


ユビキタス言語とモデル駆動設計


DDD に取り組むには、まず、

・ユビキタス言語(コードにも、業務の言葉を使え!)
・モデル駆動設計(コードの前に、モデリング)

への発想の転換が必要。

ユビキタス言語については、とにかく、コードも、日報も、業務の言葉を使おう運動で、なんとか、意識改革。

モデル駆動設計は、ICONIX プロセスに取り組んだのが、うまくいった。
ドメインモデル、クラス図を描いてレビューすることが日常の作業になった。

ここまでが、一番たいへんだったのかもしれない。
ドメイン駆動設計の入り口に、ようやく、たどりついた、という感じかな。

それでは、基本テクニック(パターン)の実践の振り返り。

Assosiations ( 関連の最小化の原則 )


ドメイン駆動設計の考え方の通り、重要な関連だけに限定してモデリングする、ことができるようになってきた。

とにかくに関連を表す線を引きまくることはなくなった。
関連が一本もないクラス図も見なくなった。

いちおう、モデル上の関連と、Java の参照や SQL という実装とも連動するようになってきているかな。

課題としては、まだまだ関連の使い方が「浅い」。

ドメインの知識を収集し、深く理解するための分析手段として、モデリングの要素「関連」を活用できているか?
そこまではいっていない感じ。

でも、関連の有無、方向性、多重度などはレビューで話題になるので、レベルアップが期待できそう。

Entities パターン (識別オブジェクト)


これは、たぶん、ぴんときていない。

・オブジェクトをシンプルに小型に
・オブジェクトの役割を単純に

ということはできている。

結果的に、Entity オブジェクトらしきものを発見・設計・実装はしている。

でも、「識別」という視点でのモデリングを意識的にやっているレベルではない。

まだ、「識別」というと、データベースの主キーや一意制約とか、オブジェクトIDとかと理解がごっちゃ。

ビジネス上の意味を持たない、サロゲートキー(代替キー)という実装テクニックの視点が強すぎる。

ドメイン駆動設計の Entities パターンは、ビジネスの現場で意味を持っている、ナチュラルキー(自然キー)に注目すること。

業務のモデリングをする時に「ビジネスの現場でキーにしている情報」というドメイン駆動の視点を持つように、レビューとかで指摘を続けようと思う。

Value Objects パターン (説明オブジェクト)


これは、初心者向けに、

・オブジェクトは小さくする
・できるだけ不変にする

というルールでやっているので、それっぽいモデリングと設計・実装になってきた。
前にあげた、BusinessDate などが、うまくやっている例。

時間とともに、 役に立つ、気の利いた、 Value Object を増やしていけそう。

Services パターン


意識的に、このパターンを使った、モデリングはできていないなあ。

たぶん、ドメインモデルのレイヤ化とかで Policy レベルのオブジェクトのモデリングとかを意識できるようになると、自然に、Services パターンがぴんとくるようになると思う。

ドメインモデルのレイヤ化は、いまは、初心者向けの「ごっこ」の状態。

とりあえず、レイヤ別に

・Decision
・Policy
・Operation
・Resource

というパッケージを作っている。
(こういうテクニカルなパッケージ分割は、アンチパターンなんですけど)

Modules パターン


パッケージ図は、前よりは使うようになったかな。

・パッケージを小さく保つ (クラスは多くても10個程度)
・依存関係に気にする

ことが、少しできはじめたレベル。

日常の作業の中で、パッケージ図に整理してみたら、全体がわかりやすくなった、という体験をする機会が少しでてきた。
パッケージを使う動機付けとスキルのレベルアップは、なんとかなりそう。

総括


Domain-Driven Design 5章までの、ドメイン駆動設計の基本事項については、

・いちおう、実践するようになった
・もっと、意識的に使えるレベルを目指す
・部分的だけど、自律的に発展できそうな感じはでてきた。

3年くらいかかって、こんな感じ。

・朝から晩まで、エディタでコードと格闘
・視点も用語も、実装技術一辺倒

こういうチームが3年でここまで変わったんだから、けっこうすごいことかもしれない。

コメント
コメントする









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