3. ドメイン駆動設計への道 設計の改善 ドメインの理解 ・メソッドの構成 オブジェクト指向 ・オブジェクト間の特性移動 設計のスタイル 言葉の力 基礎訓練 ・データの再編成 モデル駆動 ・条件記述の単純化 責任駆動設計 エクササイズ ・メソッド呼び出しの単純化 役割ステレオタイプ ９つのルール 小さく作る 責任割当の原則 GRASP For 実装の原則 Thoughtful Developer ・クラス Leading Designer ・振る舞いとメソッド ・状態とコレクション 契約による設計 4. ドメイン駆動設計への道 シンプルな ﾄﾗﾝｻﾞｸｼｮﾝｽｸﾘﾌﾟﾄ リッチな 大きな ﾄﾗﾝｻﾞｸｼｮﾝ 泥団子 ｽｸﾘﾌﾟﾄ リッチな シンプルな ドメインモデル ドメインモデル アーキテクチャなし 汎用データ型 テーブルと対応した 業務の言葉で組み立てる 汎用命名ルール ドメインオブジ
これから述べる分散オブジェクト・アーキテクチャに近いフレームワークやアプリケーションの実装がすでにあれば教えて頂けると助かります。 背景：ゼロベースの管理会計システムを開発するよ。 （凡例：追記と削除） 目的 ドメイン駆動設計(DDD)を原理的に突き詰めたアーキテクチャによって、オブジェクト指向プログラミングの作業から、インフラストラクチャ層に関する配慮がほとんど不要になる。SQLもデータスキーマ設計も不要になる。 といっても、Ruby on RailsのActiveRecord的な話ではないので、誤解なきよう。むしろ正反対。リレーショナル・データベースを使わない。 ドメインのオブジェクトをシンプルに書けばシステムが実現するようになる。一言で言えば、「GOOS/DDD原理主義者のためのフレームワークが欲しい」という話。 ウェブ・アプリケーションの三層アーキテクチャ再考 ウェブ・アプリケーシ
６月２３日（土）午後、大阪で、ドメイン駆動設計について、しゃべる予定。 第47回 SEA関西プロセス分科会のご案内 紹介の紹介の紹介、みたいな不思議なつながりで、講演の依頼があった。 「ドメイン駆動設計」を監訳された今関さんも参加いただける。 土曜の午後なので、時間が多め。 一方的にしゃべって終わりではなく、今関さんも交え参加者で、いろいろ話す時間を一時間以上とってもらいました（さらに懇親会もゆっくりと）。とても楽しみなイベントです。 ドメイン駆動設計は、訳本がでてから、あちこちで勉強会や読書会が開かれているようだし、ドメイン駆動設計に興味持ったり、現場で取り組む人が、すごく増えた気がしている。 ネットで流れる情報も「ドメイン駆動ってなんぞや？」的なものだけでなく「私は、こう理解している、やっている」的なものが多くなったんじゃないかなあ。 訳本の威力は絶大。 さて、講演の準備は、いつものよ
Menu Top JavaEE勉強会 参加するには FAQ MakingSenseofStreamProcessing MicroservicesVsSOA ModernJavaEEDesignPatterns BSA EIP DSL DDD 議事録 最新の20件2023-11-24 MicroservicesVsSOA/The World of Service-Based Architectures 2020-11-14 DDD/Knowledge-Rich Design MakingSenseofStreamProcessing/Example Implementing Twitter 2020-10-28 EIP/Aggregator 2019-12-18 EIP/Publish-Subscribe Channel 2018-06-10 FrontPage 2017-07-08 Ma
BOUNDED CONTEXTモデルのなわばり俯瞰図所属するストーリの俯瞰図です。大規模戦略編どういうこと？巨大なプロジェクトになれば、複数の異なったモデルが存在することになります。これらは無理矢理一つのモデルに統一するのではなく、それぞれのドメインモデルに「境界」を設け、明確な適用範囲を定めるようにします。どうして？別々のモデルに基づくコードが組み合わさると、バグの温床となり、信頼できなくなり、理解しにくくなります。メンバ間のコミュニケーションも混乱することになります。どうすれば？コンテキストを定義するモデルが適用される範囲を「コンテキスト」として明示的に定義します。明示的な境界は、「チーム編成」「アプリケーションの用途」「コードベース」「データベーススキーマ」などの、物理的表現の観点に沿って設定します。一慣性を保つその境界内では、モデルを厳密に一貫性のあるものに保ちます。境界の外部の問
CLOSURE OF OPERATIONS貰ったものを返す俯瞰図所属するストーリの俯瞰図です。モデル「深」化どういうこと？操作の結果として、その引数と同じ型のオブジェクトを返すような操作を「閉じた操作」といいます*1。「閉じた操作」を導入すると、引数と戻り値が同じ型になるので、そこに余計な概念（クラス）を呼び込まなくて済むようになります。どうして？有用なオブジェクトの操作は、引数や戻り値の型がプリミティブ型には収まらないことが多くなります。操作の引数や戻り値に新しいクラスが登場すると、それは新たな依存関係の導入になってしまいます。どうすれば？引数の型＝戻り値の型戻り値の型が引数の型と同じにできる場合は、そのように操作を定義します。メソッドの所属オブジェクトの型＝メソッドの戻りの型メソッドの所属してるオブジェクトは、メソッドがそのオブジェクトの状態を使用していれば、そのオブジェクトは事実上メ
STANDALONE CLASSES概念の疎結合俯瞰図所属するストーリの俯瞰図です。モデル「深」化どういうこと？人間の頭が一度に考えられる概念の量には限界があります。ドメインモデルを分かり易くするには、一度に考えなければならない概念の量を絞って、精神的な負荷の少ないモデルにする必要があります。そこで、関係のないクラスへの依存関係を極力排除して、それぞれが独立したクラスを作るようにします。どうして？無秩序に依存関係が加わると、設計が極端に難しくなります。精神的な負荷が大きくなり、開発者が処理できる設計の複雑さを超えてしまいます。どうすれば？自己完結型クラスの作成オブジェクトのイメージの中から、自分に関係のない概念をすべて取り除きます。クラスは完全に自己完結し、単独で調べて理解できるようになります。自己完結型のクラスは、モジュールを理解する際の負担も軽減してくれます。低結合はオブジェクト設計の
CONCEPTUAL CONTOURS概念の高凝集俯瞰図所属するストーリの俯瞰図です。モデル「深」化どういうこと？ドメインにはいくつもの概念が隠されていいます。凝集度の高い概念群の間には、目に見えない境界線、つまり「概念の輪郭」が存在します。モデルのリファクタリングを何度も繰り返すことで「概念の輪郭」を見つけ出し、オブジェクトの粒度がその輪郭に沿うようにします。どうして？オブジェクトの粒度は、闇雲に粗くしてはいけません。モデルや設計の要素が一枚岩の構造に埋め込まれていると、機能は重複します。役割が大きすぎると、外部インタフェースが、クライアントが重要だと思うことをすべて伝えるが難しくなります。さまざまな概念が混在しているため、要素の意味を理解するのも難しくなります。オブジェクトの粒度は、闇雲に細かくしてはいけません。クラスやメソッドを無意味に分割してしまうと、クライアントが複雑になってしま
ストーリの俯瞰図です。モデル「深」化どういうこと？操作の呼び出しによって、オブジェクトの状態が変化することを「副作用」と言います。副作用を伴う操作を「コマンド」といい、「プロシージャ」として実現されます。副作用を伴わない操作を「クエリ」といい、「ファンクション（関数）」として実現されます。「コマンド」が複雑に組み合わさって行くと、プログラムの振る舞いを理解するのが極端に難しくなってしまいます。できる限り「クエリ」操作を作成し、「コマンド」操作を必要最小限にとどめるようにします。操作の種類実現方法説明コマンドプロシージャオブジェクトの状態を変化させる。（＝副作用がある）クエリファンクションオブジェクトの状態を変化させない。（＝副作用がない）どうして？複数のルール間に存在する相互作用や、演算の合成は、予測するのが極端に困難になります。操作を呼び出す開発者は、結果を予想するために、呼び出し先の実
INTENTION-REVEALING INTERFACES名前重要俯瞰図所属するストーリの俯瞰図です。モデル「深」化どういうこと？クラスやメソッドには、意図が正確に伝わるような「名前」をつけるようにします。クラスやメソッドの名前というのは、開発者同士がコミュニケーションするための絶好の場所です。このコミュニケーションをスムースにするため、名前には最大限の配慮を払います。どうして？オブジェクト指向のよいところは、複雑な処理があったとしても、その責務を持ったオブジェクトが隠蔽してくれる点にあります。それによって、クライアントコードはシンプルになり、より高いレベルの概念から解釈できるようになります。しかし、クライアント開発者が、オブジェクトのインタフェースを見ても使い方がわからなければ、それを理解するためにコードの内部を解析しなければならなくなります。クライアントコードを読む人も同じことをしな
PROCESS「手続き」をモデル化俯瞰図所属するストーリの俯瞰図です。モデル「深」化どういうこと？モデルにおいて、ビジネス上意味のある「プロセス」というのは確かに存在します。ただし、既存のドメインオブジェクトにあてはめようとすると、「プロセス」の特性上、オブジェクトの設計がぎこちないものになってしまいます。そこで、「プロセス」という観点でモデリングを行い、通常オブジェクトとは切り離してモデル化します。どうして？オブジェクトは、手続きをカプセル化し、代わりに目的や意図にフォーカスさせるために存在します。「プロセス」は手続きそのものなので、この考え方に当てはまりにくい部分です。既存のオブジェクトに無理やり押し込めると、オブジェクトの責務があいまいになり、ぼやけた設計になってしまいます。どうすれば？選定明示すべきプロセスと隠蔽すべきプロセスを区別する鍵は単純です。ドメインエキスパートが話題に上げ
CONSTRAINT制限事項の見える化俯瞰図所属するストーリの俯瞰図です。モデル「深」化どういうこと？モデルの概念において、制限事項や許容範囲は暗黙のうちに現れます。これを「制約」として明示的に表現することで、設計が大幅に向上することがあります。どうして？非常に単純なルールなら、別の役割に溶け込んでいても問題ありません。しかし、強制すべきルールが複雑になれば、（あらゆる暗黙的な概念と同様に、）ルールが適用されるオブジェクトや操作を圧倒し始めます。どうすれば？独立メソッド化「制約」を（暗黙からあぶり出し、）メソッドとして独立させます。呼び出し側を自分のやるべきことに専念できる状態に保ちながら、必要に応じて制約の側を複雑にすることができます。そのメソッドに意図の明白な名前をつけるようにします。「制約」に名前を与えられることになり、議論することが可能になります。独立オブジェクト化メソッド独立させ
SPECIFICATIONルール専用オブジェクト俯瞰図所属するストーリの俯瞰図です。モデル「深」化どういうこと？ビジネスルールをドメインモデル上で表現するために、論理プログラミングの「述語（Predicate）*1」概念の役割を持つ値オブジェクトを、「仕様」として導入します。仕様は、以下の3つの概念のルールを、一貫性を持って規定します。検証：オブジェクトが、ある要求を満たしているか、ある目的のための用意ができているか、を検証します。選択：コレクションから、ある条件を満たしたオブジェクトを選択します。構築：要求に適合する、新しいオブジェクトの構築を定義します。どうして？ビジネスルールは、どの「エンティティ」「値オブジェクト」の責務とも合致しないことがあります。既存のオブジェクトに無理やり押し込むと、ルールの多様性と組み合わせが、ドメインオブジェクトの本来の意味を埋没させてしまいます。かといっ
書籍「エリック・エヴァンスのドメイン駆動設計」の「第３部 より深い洞察へ向かうリファクタリング」で紹介されているパターンをまとめます。目次「暗黙的な概念」を明示するパターン*1仕様（SPECIFICATION）制約（CONSTRAINT）プロセス（PROCESS）変更を支える「しなやかな設計」のパターン 抽象化 意図の明白なインタフェース（INTENTION-REVEALING INTERFACES）副作用のない関数（SIDE-EFFECT-FREE-FUNCTIONS）表明（ASSERTIONS）分割 概念の輪郭（CONCEPTUAL CONTOURS）独立したクラス（STANDALONE CLASSES）閉じた操作（CLOSURE OF OPERATIONS）俯瞰図本ストーリの俯瞰図です。モデル「深」化「深いモデル」への道程 *2前編「アプリケーション構築編」のパターンで、アプリケーシ
REPOSITORIESオブジェクト参照のカプセル化俯瞰図所属するストーリの俯瞰図です。アプリケーション構築どういうこと？ライフサイクルを開始したドメインオブジェクトは、データとして不要になり削除されるまで、（たとえメモリ上になくても、）データベースに永続化されるなどして生存し続けます。このデータベースへの永続化や問い合わせ処理は、ドメインの本質ではありませんし、複雑になりがちな部分です。そこで、データベースへの永続化や問い合わせ処理を専用に行う「リポジトリ」をドメインの設計に導入し、オブジェクト参照の入手の便宜を図ります。どうして？ドメインオブジェクトへの参照手段が統一されていないと、クライアントが各々それを実現しようとしてしまいます。これでは、モデルが混乱することになります。データベースアクセスは複雑です。そうした複雑さにクライアントコードが浸食されてしまうと、開発者はドメイン層を縮小
FACTORIESオブジェクト生成処理をカプセル化俯瞰図所属するストーリの俯瞰図です。アプリケーション構築どういうこと？オブジェクトの生成そのものが、ドメインモデル上で重要な意味をもつことはほとんどありません。また、オブジェクトや「集約」の生成処理は、それ自体複雑になる場合もあります。よって、「ファクトリ」を導入し、オブジェクトの生成処理をカプセル化するようにします。「ファクトリ」はモデルじゃない「ファクトリ」は、ドメイン層に所属していますが、ドメインモデルの一部ではありません。ドメインモデルは「エンティティ」「値オブジェクト」「サービス」だけです。「ファクトリ」はモデルではなく、あくまで「ドメインの設計上、必要な一要素」という位置付けになります。これは「集約」や、後述する「リポジトリ」でも同様です。
AGGREGATES境界線俯瞰図所属するストーリの俯瞰図です。アプリケーション構築どういうこと？オブジェクトのライフサイクルを設計するには、まずライフサイクルの単位となる「オブジェクトのまとまり」を考えます。ライフサイクルを共にする、関連の深いオブジェクトのグループは「集約」として扱います。「集約」を単位として、他のオブジェクトとの「境界」を明確に分けるようにします。どうして？維持すべき不変条件*1には、個々のオブジェクトに適用されるものだけでなく、密接に関連するオブジェクトのグループに適用されるものもあります。複雑な関連を伴うモデルでは、不変条件を保証するのが難しくなります。関連が複雑だと、トランザクションについても、変更による潜在的な影響の範囲が不透明になります。この問題が深刻化するのは、同一オブジェクトへの同時アクセスがあるシステムです。あまりに慎重にロックしてしまうと、複数のユーザ
MODULESグルーピングのモデリング別名パッケージ（PACKAGES）俯瞰図所属するストーリの俯瞰図です。アプリケーション構築どういうこと？モデルもコードも意味のある単位に分割し、モジュールとしてまとめます。プログラミングの場合と同じく、モデルのモジュール分割においても高凝集・低結合が重要な目安になります。関連し合う概念同士はひとつにまとめ（高凝集）、かつ一度に考えなければいけない範囲は最小限にします（低結合）。どうして？モデルも分割統治モジュールに分割されるのはコードだけではありません。概念も分割されます。モジュール内では高凝集、モジュール間では低結合が必要です。人が一度に考えられる物事の数には限りがありますし（ゆえに低結合)、首尾一貫していない思考の断片は理解するのが難くなります（ゆえに高凝集)。モジュールもモデルモジュールも、モデルの一部です。モデルを表現し、深化させなければなりま
SERVICESどのオブジェクトにも属さない操作俯瞰図所属するストーリの俯瞰図です。アプリケーション構築どういうこと？ドメインモデリングを進めていくと、概念的にどのオブジェクトにも属さないような操作が含まれることがあります。その場合、既存のオブジェクトに強引に押し込むのではなく、ドメインの輪郭に従って、「サービス」という形でモデルの中に組み込みます。どうして？ドメインから生まれる概念の中には、オブジェクトとしてモデル化すると不自然なものもあります。複数のエンティティにまたがる処理外部システムとの通信を伴う処理こうした機能をエンティティや値オブジェクトの責務として押しつけると、モデルに基づくオブジェクトの定義を歪めてしまったり、意味のない不自然なオブジェクトを追加することになってしまいます。どうすれば？独立インターフェイスを作成ドメインにおける重要なプロセスや変換処理が、エンティティや値オブ
VALUE OBJECTS性質を表現するオブジェクト俯瞰図所属するストーリの俯瞰図です。アプリケーション構築どういうこと？値オブジェクトは、同一性と連続性を持たず、属性によって定義されるドメインモデルのオブジェクトです。値オブジェクトは、事物の性質を表現します。「色」や「量」のように、その属性だけが重要で、（エンティティのように）識別を考えることに意味がありません。 // 最も単純な「エンティティ」と「値オブジェクト」 class Person /*エンティティ*/ { String /*値オブジェクト*/ name; // 識別子 } たとえば？銀行の口座を管理するシステムがあります。この場合、口座の属性である「口座種別」や「残高」のように、物事の性質を表しているオブジェクトが値オブジェクトになります。口座種別なら「AccountType」、残高なら金額を表す「Money」という型モデル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
