はじめに 最近、積み上げたまま放置してたセキュア・バイ・デザインを読み始めました。 以前エヴァンス本読んだ時も読書メモ書いたんですが、読みっぱなしより理解が深まるし、後から読み返せたりしてかなり良かったので 今回も章ごとにまとめていきたいと思…

前回のふりかえり 第16章 大規模な構造 境界づけられたコンテキストや蒸留などの方法ではシステム全体の構成は表現できないので、開発者が全体像を見えるようにする必要がある。(大規模な構造) 進化する秩序(大規模な構造の基本思想) 大規模な構造を一度に設…

前回のふりかえり 第15章 蒸留 蒸留は、モデルから副次的なものを切り落とし、本当に重要なもの(コアドメイン)に焦点を当てやすくする ドメインを、コアドメインと汎用サブドメインに分ける コアドメインをドキュメント化する ドキュメントをドメインビジョ…

前回のふりかえり 第14章 モデルの整合性を維持する コンテキストマップで用いられる、コンテキスト間の6種類の関係 共有カーネル モデルの一部を直接共有することで、少ないコストで統合しやすくなる 顧客/供給者の開発チーム 明確に顧客（使う側）と供給者…

前回のふりかえり 第14章 モデルの整合性を維持する システムが複雑になりすぎて個々のオブジェクトのレベルで理解することが出来なくなると、巨大なモデルを扱うためのテクニックが必要になる 非常に入り組んだドメインに対応させるための原則 コンテキスト…

前回のふりかえり 第13章 より深い洞察へ向かうリファクタリング リファクタリングでは、下記の3点に重点的に取り組む ドメインに馴染む 常に、物事に対して違う見方をする ドメインエキスパートとの対話を途切れさせない 生産的なリファクタリングを行うに…

前回のふりかえり 第12章 デザインパターンをモデルに関係づける デザインパターンというのは、技術的な側面に焦点をあて、一般的な設計の問題を特定のコンテキストで解決するためにカスタマイズされたもの ただ、デザインパターンの一部はドメインパターン…

前回のふりかえり アナリシスパターンを適用する アナリシスパターンは、分析のパターン。ドメイン分析の中で繰り返し現れる構造をパターン化したもの。 特定のドメインモデルを考え出すのを支援する手引きとして使う 自分たちで一からドメインモデルを模索…

前回のふりかえり 第10章③の主旨 宣言的な設計 プログラムやその一部をある種の実行可能な仕様として作成する方法 性質を厳格に記述することで、ソフトウェアを実際に制御する 設計の宣言的スタイル 設計的な設計の利点を得るには、意図の明白なインターフェ…

前回のふりかえり 第10章②の主旨 ①から引き続き、しなやかに設計するためのいくつかのパターンについて説明 表明 副作用のある操作を理解しやすい形で表現するための手法 概念の輪郭 ドメインが持つ概念(論理的な一貫性)を縁取るもの 閉じた操作 操作を一つ…

前回のふりかえり 第10章①の主旨 しなやかな設計とは、深いモデリングを補完するもの 暗黙的な概念を掘り出し、概念を簡潔かつ明確なモデルにする。洞察とリファクタリングを繰り返し、改良していく。 しなやかな設計 は開発者が気軽にソフトウェアに変更を…

前回のふりかえり 第9章(仕様)の主旨 仕様とは、エンティティや値オブジェクトの責務に合致しないビジネスルールを表すためのオブジェクト 以下の3つの目的の1つでも当てはまれば、仕様を利用する必要がある オブジェクトを検証して、何らかの要求を満たして…

前回のふりかえり 第9章(前半)の主旨 深いモデルというのは、ドメインの中心となる概念や抽象を含んでいる。 深いモデルを作るには、ドメインの本質的な概念をモデルで表現することが必要。 多くの概念は暗黙的で認識できないので、それを下記の様な方法で掘…

前回のふりかえり 第8章の主旨 ブレイクスルーとは、リファクタリングを行う中で、モデルが実際に起きていることや、ユーザーが重視するものとより深いレベルで一致するようになる現象。 ブレイクスルーが起こるのは、適度なリファクタリングが何度も行われ…

前回のふりかえり 第7章の主旨 ファクトリ・リポジトリなどのパターンを実際のプロジェクトにどう適用するかの説明 第3部 より深い洞察へ向かうリファクタリング DDDがやりたいのは、ドメインについての深い理解をとらえたモデルを見つけること ↑のモデルが…

前回のふりかえり 第6章(リポジトリ)の主旨 DBなどに永続化されたオブジェクトを取り出してインスタンス化する(再構成する)クラス リポジトリが上記の責務を負うことで、永続化層への問い合わせ処理をカプセル化し、モデルに焦点を合わせられるようにする 第…

前回のふりかえり 第6章(ファクトリ)の主旨 ファクトリはオブジェクト生成を責務として担うもの オブジェクトや集約の複雑な生成作業をファクトリに任せることで、オブジェクト本来の責務に集中することができる。 第6章 リポジトリ(REPOSITORIES) DBなどに…

前回のふりかえり 第6章(集約)の主旨 ライフサイクルの長いオブジェクトの整合性を保つことが、ドメインオブジェクトを扱うことの課題になってくる。 そのような課題に立ち向かうために 集約・ファクトリ・リポジトリといった要素を使う。 集約は関連するオ…

前回のふりかえり 第5章の主旨 モデルを構成するものとして エンティティ・値オブジェクト・サービス の3つの要素がある。 オブジェクト間の関連・結合度を下げることで1つ1つの要素に集中することができ、ドメインを扱いやすくする。 モデルの本質的な(その…

前回のふりかえり 第4章の主旨 MDDを実現するには、モデル要素であるドメインオブジェクトを、他の機能から分離させる必要がある。 その手法として、レイヤードアーキテクチャを利用できる。 ドメイン層として凝集度を高め、他の層から独立させる。 第5章 ソ…

前回のふりかえり 第3章の主旨 モデル駆動設計では、分析と設計で同じモデルを使う 分析と設計で別のモデルを使用すると、それぞれの作業で得られた洞察を反映できなくなる モデルと設計(≒コード？)はお互いが対応してなければならず、一方と変更したら他方…

前回のふりかえり 第2章の主旨 開発者とドメインエキスパートは、 ユビキタス言語 という共通の言語を使ってコミュニケーションする。 ドメインについて、その表現で合っているのか絶えず議論・実験して、ユビキタス言語を変更していく(=ドメインモデルを変…

前回のふりかえり 第1章の主旨 知識をかみ砕くことで、チームの持っている知識が価値のあるモデルとして変わることができる。 知識のかみ砕きは、皆が持っている情報(ドメイン・技術)を集めて、大部分の意味を理解できるシンプルな見方を見つけようとする作…

はじめに 最近エヴァンス本を読み始めました。 理由としては下記の3点です。 職場でDDDを取り入れ始めたけれど、DDDについて断片的な知識しか持っていない。 上記の理由から「DDDとは何なのか」を学んで、自分の中に土台を作りたい。 DDDについて論争が起き…