朝イチからボウリング疲れた。2ゲームやってハイスコア131なのでまぁいい感じ。
DDD本読書メモ
2章 ドメイン、サブドメイン、境界づけられたコンテキスト
2.11 境界づけられたコンテキストの意味を知る
本節の最初には以下のように記されている
境界づけられたコンテキストは明示的な境界であり、ドメインモデルがどこに属するのかを表すものである。ドメインモデルはユビキタス言語をソフトウェアモデルとして表したものだ。
いきなり境界づけられたとか言われてもなんのこっっちゃよーわからん。ってなったなので、原典たる英語版での用語を漁ったら Bounded Context と書いてあった。Boundedって数学的な用語で有界のとかそういう意味らしいのだが、そういうつもりでこの言葉をBoundedとしたんじゃないかなぁと。"境界づけられた"よりも"有界の"のほうが腹落ちする。あるいは"束縛された"でもいいかもしれない。
要は、ユビキタス言語が示すコト(=ドメインモデル)がどの業務において利用されるかという言葉の定義が効く範囲(=コンテキスト)を示しているのだと思う。例えばクリエイティブという言葉は一般的には創造性みたいな形容詞であるのだが、広告業界では広告表現に利用されるオブジェクトのことをクリエイティブと呼ぶ。広告配信のプロダクトを作っていたとして、クリエイティブは広告配信業務コンテキスト内のユビキタス言語であるし、広告配信業務コンテキストが境界づけられたコンテキストとなる。
境界づけられたコンテキストの"境界"とはなにか? 個人的には問題空間上のビジネス課題(プロダクトの提供する価値)の範囲だと理解した。本書には
システムやアプリケーション、あるいは業務サービスなどを区切るために使うことも多い
と書かれているが、混乱を避けるという意味でシステム内部での用語世界の範囲決め使わないほうがいいと思った。本書に手もコンテキストのサイズを誤るパターンとして、フレームワークやシステムアーキテクチャの影響により言語的な境界から技術的な境界を考えてしまう事があると示しているしね。
境界づけられたコンテキストによりユビキタス言語やドメインモデルをカプセル化することができる。のが最大のメリット。仕事でよくモデル設計をしている時に"XXはα界の用言葉だからβ界に滲みでたらアカンよね"みたいな話を良くするのだが、その界が境界づけられたコンテキストであり、その中のドメインモデル同士がコンテキストを跨いで紐づくと美しく設計されている状態になるのであろう。
じゃあどうやって境界づけられたコンテキストやドメインモデルを設計するのという話は3章でコンテキストマップとして触れるとあるので待つ。
システム実装上は com.jsoizo.ddd のような名前空間が境界づけられたコンテキストになるし、そこからさらに com.jsoizo.ddd.controllers や com.jsoizo.ddd.models みたいな名前空間になっても基本的に同じコンテキスト内で同じドメインモデルを操作する人間が開発にアサインされた方がいい。
今日のトレーニング
メニュー
またさぼった。明日は休日なのでやろう
計測
64.25kg
会社の体重計に服を着た状態で乗ると62~63kg台なのに、家の体重計に服をほとんど着ない状態で乗ったら64kg台になる。家で測るときはだいたい夕食を食べた後だから単に重いのかもしれないが、誤差は結構あるなぁ。
