Domain-Driven Design(DDD)の III部は、「ドメイン駆動設計」のリファクタリングがテーマ。 開発者が、問題領域をより深く理解し、それを、より正しく、コードで表現するための、 ・考え方 ・やり方 を「リファクタリング」というキーワードで、いろいろなパターンや例を８章から１２章までの５つの章にわたって説明している。 III部の最後の章、13章は "Refactoring Toward Deeper Insight" 。これは、III部のタイトルをそのまま使っている。III部を総まとめした内容。 ドメイン駆動設計のリファクタリング ドメインを深く理解するためのモデルとコードのリファクタリングは「伝統的なテクニカルなリファクタリング」の考え方、やり方に、次の三つのポイントを重ね合わせたもの。 （１）「ドメイン層」の活動である （２）（従来のリファクタリングとは）異なる点にも

昨日の記事、自分で読み返した。「分析パターン」をネガティブに書きすぎた。 自分は、もっと、分析パターンを積極的に使っている。 そういう前向き（？）な内容で、改めて、分析パターンの利用について。 Entities パターンのヒント Domain-Driven Design(DDD)の Entities パターンで実現するドメインオブジェクトって、もうちょっと具体的に言うと、何があるんだろう？ ・エンタープライズアプリケーションで、「識別」したいものは何？ ・識別の単位は？（みじんぎり、それとも、どーんとひとかたまり?) 初期のモデルのネタ探しとか、開発中に、モデルに違和感がでてきた時の、別案さがしとかに、分析パターン本は、役に立つ。 クラス名のヒント集として使える。 Hruby の「ビジネスパターンによるモデル駆動設計」 Entity を、さらに三種類に分けている。 Resource, Ev

実際のコードで、小さなリファクタリングを繰り返しながら、ドメインの理解を深めていく。 このやり方が基本だと思うし、確実に効果はある。 でも、このやり方だけでは、現実的には、時間が足りない。 経験豊富な開発者であれば、得意の分野であれば、プロジェクトの最初から、相当にレベルの高いモデルとコードから、スタートできる。 そういう経験豊富な開発者の頭の中にある、モデルや設計を、流用できれば、初期モデル、初期の設計を、ある程度のレベルのところからスタートできる。 これが、Domain-Driven Design(DDD) 11章 "Applying Analysis Patterns(アナリシスパターンを適用する)" のテーマですね。 私が利用しているビジネスパターン エンタープライズアプリケーションの概念モデルは、あきらかに、類似性があります。 例えば、会計とか契約とかに関係するビジネスルールや業

Supple Design （しなやかな設計)のパターンと設計スタイルは、主な適用範囲は、狭い範囲ですね。 ビジネスロジックのちょっとしたかたまりを、Money とか、 BusinessDate とか、PersonName とか、役割が単純で、独立した、プリミティブなドメインオブジェクトにカプセル化する作業。 こういう単純だけど、役割が明確なドメインオブジェクトが揃ってくると、全体のコードがわかりやすくなる。 その結果、もっと、大きなモデリングや設計の課題に取り組みやすくなる。 レイヤ構造 Supple Design を地道に実践していくと、ドメインオブジェクトの群れが、レイヤ構造になってくる。 上から、 アプリケーションサービス層　　ドメインモデルを使う側、クライアントコードの置き場所 ドメインモデル層　　問題領域の知識が豊富 ( knowledge rich )なドメインモデルの本体

Domain-Driven Design の１０章 Supple Design ( しなやかな設計 ) は、ドメイン駆動設計を実践していくための、設計・実装の基礎テクニック集なんだと思います。 ・ドメインをより深く理解して、ほんとうに役に立つソフトウェアを開発する。 ・隣接ドメインを含めて、より広い範囲の問題に取り組む。 この章の基礎テクニックを習得して、日々の設計・実装で、ふつうに使えるようになると、ドメインをもっと深く理解し、もっと広い問題に取り掛かる、土台がしっかりしてくる。 ソースコードが改良され読みやすくなり、開発者のドメイン駆動設計の実践スキルがしっかりしてくる。 どこから手をつける？ エバンスは、１０章の最後で、広い範囲を、一気に手をつけると、エネルギーが分散してしまう。まず、狭い範囲に絞って、そこで、じっくりと「しなやかの設計」の基礎テクニックを実践してみることを薦めていま

やっぱり宣言的スタイルでしょう エバンスは、ドメイン駆動設計の１０章で、「宣言的スタイル」の良さを説いている。 ケントベックも「実装パターン」の「原則」の一つとして、「宣言的な表現」が良いと言っている。 私自身は、SQL 文や、XML のように宣言型の言語 ( if や for のない言語 ) が好きなので、こういう人たちが、「宣言的がいいんだよ」と、書いているのを見つけちゃうと、「そうそう、やっぱり宣言的スタイルだよねえ」と、勝手に納得しちゃっている。 あまり、深く考えたことはないけど、Java とかも、できるだけ、how 指向ではなく what 指向、つまり、宣言的なスタイルのコードの方が、読みやすいし、変更もやりやすいと思っている。 手続き大好きの人が多い？ そんな、「宣言スタイル大好き」派の私からみると、多くの開発者は、手続き型に書きたがるなあ、というのが実感。 たぶん「宣言的」な

Domain-Driven Design(DDD)の１０章 Supple Design ( しなやなか設計 ) のテーマは、ソフトウェアを、 ・わかりやすく ・テストが簡単で ・変更がやりやすく する設計の考え方ややり方。 １０章の６つのパターン 具体的には、６つのパターンで説明している。 ・Intention-Revealing Interface : 名前をちゃんと考えてつける ・Side-Effect-Free Functions : 副作用を減らす設計 ・Assertions : 怪しいところには「注意書き」 ・Conceptual Contours : オブジェクトの粒度は、ドメインの概念とあわせる ・Standalone Classes : スパゲティにしない設計＜依存を最小に＞ ・Closure of Operations : スパゲティにしない設計＜同じ型に閉じる＞ 別の設

システム設計日記を検索 プロフィール masuda220 リンク システム開発日記(実装編) 有限会社 システム設計 twitter @masuda220 selected entries Closure of Operations パターンと動的型付けの関係 (12/18) recent comment Smart UI が優れている？ ⇒ masuda220 (03/10) Smart UI が優れている？ ⇒ kagehiens (03/09) オブジェクト指向プログラミングの教え方？ ⇒ masuda220 (12/05) オブジェクト指向プログラミングの教え方？ ⇒ ZACKY (12/04) 「オブジェクトの設計力」　スキルアップ講座やります ⇒ masuda220 (08/14) 「オブジェクトの設計力」　スキルアップ講座やります ⇒ kompiro (08/14) 「オブジ

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

これも、他のクラスへの依存をできるだけ減らす「疎結合」を重視した設計テクニックの一つですね。 メソッドは、自分と同じ型を受け取り、自分と同じ型を返すべし 簡単な例： Money baseCharge = new Money( 1000, "YEN" ); Money extraCharge = new Money ( 500, "YEN" ); Money tatolCharge = baseCharge.add( extraCharge ) ; Money クラスの add() メソッドは、パラメータが Money で、戻す値も Money 。 これが　Money に「閉じている」操作 ( Closure of Operations )。 "closuer" という言葉は、「封鎖」とか「通行止め」という感じで、力づくてとめている感じ。 操作（メソッド）のパラメータと戻す値を、自分自身の型

ドメイン駆動設計(DDD) の Standalone Classes パターンは、クラス間の依存を少なくし、疎結合にするのがテーマ。 私は、コードレビューの時、この結合の度合いは、かなり気にしてチェックしています。 といっても、そんなに難しい話ではなく、Java だったら、 import 文の数を見るだけ。 import は、クラスごとに宣言 コーディングの約束ごととして、import は、必ずクラス単位で宣言する。 "*" を使って、パッケージ全体の import 指定は不可。 こういう import 文の構成は、IDE が面倒みてくれるので、楽チンですね。 import に行数が多い コードの中身をみなくても、先頭の import 宣言の行数を見れば、「結合」の度合いは一目瞭然。 ・import が少ないほど、疎結合。(もちろん、良い設計) ・import が多いほど、密結合。（もちろ

たくさんのオブジェクトが、からみあってくると、ソフトウェアは手がつけれなくなる。 いわゆるスパゲティコード。 ・読みにくい（理解しがたい） ・テストコードが書きにくい（特に、セットアップ） ・変更がしにくい／こわくてできない ．．． スパゲティにしたいわけじゃない。でも、いつのまにか、そうなっちゃう。 こうならないために、どんな設計・実装をこころがけるべきか？ 「依存」を見たら、泥棒と思え 当たり前のように使っている、コードの中の依存関係。 ・インスタンス変数で他のオブジェクトへの参照を保持 ・メソッド内の一時変数で他のオブジェクトへの参照を保持 ・メソッドのパラメータで渡ってくる、他のオブジェクトへの参照 ．．． こういう「依存性」を、すべて疑ってかかる。 スパゲッティになりたくなかったら「全て」を疑う。 「ほんとうに必要か？」 「他のやり方があるのでは？」 参照やパラメータ渡しがあるか

Conceptual Contours パターンは、ドメインオブジェクトは、ドメインの概念（用語）をくっきりと表現すべき、という設計の考え方。 顧客の住所を例に考えてみる。 郵便番号をさらに分解 粒度設計を「みじん切り」方式にすると、 class MajorPostalCode { String code ; // 郵便番号の上３桁 } class MinorPostalCode { String code ; // 郵便番号の下３桁 } になる。 これは、おそらくほとんどのドメインで「概念の輪郭」になっていない。 上記のサンプルコードの、コメントを見てもらえばわかるとおり、MajorPostalCode を表す、ぴったりの言葉（概念）が、ない（らしい）。 こういうレベルまで、分解してしまうのは、ドメインオブジェクトとしては、まずい設計ということ。 入力フィールドを３桁−４桁に分解する、と

オブジェクトの大きさは、いつも悩ましい問題。 Conceptual Contours パターン ( 概念の輪郭線 ) は、ドメインオブジェクトの粒度をうまく設計するための手がかり。 やりがちな方法 まずは、粒度設計の、やりがちな方法を三つ。 みじんぎり とにかく小さくわける。 小さな部品だと、どこでも、いつでも手軽に利用できる。 部品は小さいほど、再利用しやすくなる。 コンピュータがそもそも、bit という最小単位を扱うから、多目的に使える。 でも、なんでも bit で考えるのは、さすがにしんどい。 大きな塊 オブジェクトは、複雑な処理やデータ構造を、内部に隠蔽してくれるから、役に立つ。 「顧客登録」とかの単位で、どーんとひとつの塊にして、詳細を隠蔽すれば、利用しやすい。 でも、ばっかでっかいクラスだと、どこで何をしているのか、理解するだけでも一苦労。 お隣を見れば、もうひとつ、顧客がらみ

ドメイン駆動設計(DDD)の１０章「しやなかな設計」は、副作用の心配なしに、安心して使えるオブジェクトを設計・実装するのがテーマ。 Value Object と Service オブジェクトは安心 Value Object は、不変( imutable ) にして、副作用なしにするテクニック。 だから、Assertion は不要(のはず）。 Service オブジェクトも、内部に「状態」を持つべきではない。 状態がなければ、メソッドの副作用もない。 こちらも Assertion は不要(のはず）。 問題は、Entity オブジェクト そうすると、Assertion を使う候補は、Entity オブジェクトだけ、というわけだ。 Entity オブジェクトは、Aggregate のルートとして、いろいろな「状態」を持つ。 Value Object を使う側だから、操作の前と後で、別の状態になる

Repository パターンを書いた記事で、「相互依存性」について興味深いコメントをいただきました。 現実の業務アプリでぶつかる、とても重要な設計課題だと思います。 私なりの、やり方のアイデアをざっと整理してみました。 コメントいただいた内容（抜粋） > でも、「ビジネスパターンによるモデル駆動設計」にある経済減少イベントと経済増加イベントのように対等なエンティティでは、相互依存関係をどのように解決すればいいのかわかっていません。業務要件上はこの2種類のエンティティは区別されなければならないので、困ったもんだなーとｗ > BusinessIncrementRepositry > BusinessDecrementRepositry > なるものを作っても、相互依存関係は解消されないなーと。 > こういう場合の何かよいアイデアとかお持ちではないでしょうか？ 「ビジネスパターンによるモデル駆

コードが複雑になってくると、「副作用」が恐くて、コードを変更しにくくなる。 ちょっとした変更が、とんでもないところに影響がでる。 すぐに発覚するなら、まだまし。 本番リリース後、しばらくたってから発覚する「副作用」には、なんども痛い目にあわされてきた。 副作用の原因 ソフトウェア変更後の予想外の障害を調べてみれば、コードに「こうしろ」と書いてある箇所があり、コンピュータは、まじめにそれを実行しただけ。 副作用を起こしたコードの場所が、変更した箇所からは、遠く離れていて、変更した技術者には想像もつかなかったのが原因。 ・あるオブジェクトの一つのメソッドを実行する ・メソッドの中で別のメソッドを呼び出す ・その中で、今度は、オブジェクトを生成し、そのメソッドを呼び出す ・またメソッドを呼び出す ．．． 少し規模の大きいソフトウェアでは、普通の姿ですね。 シンプルで役割を明確にするために、小型の

ドメイン駆動設計(DDD)の「しやなかな設計 (Supple Design)」の最初のパターンは、 Intention-Revealing Interface 意図の明確なインタフェース。 ようするに、わかりやすいクラス名、メソッド名をつけるということ。 これ、あたりまえだけど、かなりレベルの高い設計スキルだと思う。 わかりやすい名前とは？ ドメインオブジェクトを使う側の立場で考える。 わかりやすいインタフェースの例 クラス名とメソッド名を見れば直感的に、使いか方がわかるのが、ベスト。 date.isSummer() は、なにをしているか、直感的にわかりやすい例。 API　ドキュメントが欲しくなる わかりにくい、クラス名、メソッド名だと、API ドキュメントをしょっちゅう読むことになる。 わかりにくい悪い名前。 date.check( String type ) API ドキュメントで、S

Domain-Driven Design(DDD)の１０章 "Supple Design (しなやかな設計)"は、この本の中では、ちょっとかわった章です。 この章だけは、 ・開発者の視点で ・開発者のための良い設計 にフォーカスしている。 業務の専門家にとってどうか、とか、ソフトウェアの利用者にとってどうか、という議論はまったくでてこない。 ある意味、ドメイン駆動設計らしくない章になっている。 （もちろん、開発者にとっては、面白いし、参考になる内容ばかり） 良い設計ってなんだ 良いソフトウェアは、利用者にとって役立つこと。 でも、この章では、良いソフトウェアのもう一つの側面、「開発者にとって良いソフトウェア、良い設計」に焦点をあてている。 キャッチフレーズは、 "a design that is a pleasure to work with" ふれるのが楽しくなるコード、という感じですか

Domain-Driven Design(DDD)の９章 "Making Implicit Cocepts Explicit" ( はっきりしない概念を明確にする) では、かなりのページを使って、Specification パターンを説明している。 ・仕様を満たすこと ・こういう条件を満たすこと という種類のビジネスの約束事を表現するドメインオブジェクトの設計・実装パターンの議論。 エバンスは、このパターンがお気に入りらしく、１８ページを使って解説している。 はっきりしない概念として取り上げた「制約(ビジネスルール)」と「業務手順」の議論は、たったの４ページなのにね。 動機：複合条件を表現する 単純な if 文で判定できる場合は、良いけど、 ( Java 経験５年以上 OR C# 経験５年以上) AND ( 東京在住 OR 転居可能 ) AND ( 文系 OR 読書好き ) AND ( 好