Product ManagerのSlack眺めてる。有名な会社のCEOやらCTOやら居てビビる。バックグラウンドに技術がありつつプロダクトの価値とか組織とかを語れて、スーパーマンに見える。そういう人になりたい。あと3~5年くらい後かな? 眺めてるだけでも学ぶこと多い。一方で、発言しようと思って内容整理していたら会話が流れていったりって事があって、自分のアウトプットのスピード感のなさに辟易した。こういうブログとかを毎日書くことでスキル向上したらいいな。
DDD本読書メモ
2章 ドメイン、サブドメイン、境界づけられたコンテキスト
実世界における2.10 ドメインとサブドメイン
昨日の続き.
ドメインは問題空間と解決空間を持つ。本には以下のように書かれている。
- 問題空間 : ビジネス戦略上の課題を浮き彫りにする
- 解決空間 : ソフトウェアの実装課題を解決する
問題空間=要求定義, 解決空間=要件定義 的な理解をした。問題空間は過去のドメインやいくつかのサブドメインからプロダクトのコアドメインをつくる場所。つまり、プロダクト自身の価値は何?それがユーザーのどんな問題を解決するってことを定義する(※解決しないことを定めるのも大事ね)。ここを履き違えると以降のプロセスがグズり、有名な↓の画像みたいな状況に陥る。
本書には問題空間の理解にアセスメントビューが使えると書いてあったが、その説明がなかったのでさっぱり。
解決空間においてはプロダクトを構成するシステムを定義する、ソフトウェアモデルの集合。ソフトウェアモデル同士は境界づけられたコンテキストによって区切られる。問題空間にて定義したドメインをシステムとしてどう表現するかがポイントかな。ドメインがそのまま境界づけられたコンテキストになればいいが、実体として同じドメインを複数のソフトウェアが利用することがほとんどだ。
務めている会社ではドメインモデルをjar化して複数のScalaアプリケーションで使いまわすということをしている。残念なことにリポジトリ層とモデルがべったりくっついた状態(ライトDDD?)なので改善の余地有りだが、リポジトリがほぼRDBMSと決まっているのでまぁ無理に分けなくても良かったのかもしれないとも思う。
めも
Eric EvansのDDD本にある戦術的パターンがところどころ出てくるので参照してみよう。
今日のトレーニング
メニュー
仕事忙しくてさぼった。明日は行きたいが飲み会あるのでどうしようか。
計測
62.85kg