赤シャツエンジニア

赤シャツエンジニア

SCRUMMASTER THE BOOK読書会第1回、第2回に参加して

スクラムアジャイル未経験にもかかわらず、SCRUMMASTER THE BOOK読書会第1回、第2回に参加させていただき、学びがあったので、ざっくばらんに書きなぐります。

scrumdo-kansai.connpass.com

scrumdo-kansai.connpass.com

スクラムの導入のされ方

会社方針として導入されるトップダウンスクラムを面白いと感じて導入されるボトムダウンがあると思いました。 トップダウンで導入される分には、スクラムマスターなどの役職や枠組みが用意されるので、 その分の時間をとって取り組むことができるメリットがありますが、実践する人がやる気がなかったり知識をつけようとしなかったりすると 形骸化する可能性が高いと感じました。

一方、ボトムアップでの導入のデメリットは活動に対して時間や評価が与えられにくいということです。 経営陣や上司が理解を示してもらえない場合、導入する

スクラムの導入するステップは?

第一回でも第二回でも語られていましたが、全部をいきなり導入するのはかなりハードルが高いとのことでした。 ならばどうするか?オススメなのは「振り返り」から導入してみるのはどうかということでした。 とにかくスプリント単位で振り返りだけはやってみる。言い換えるとケツからやるということになります。 これを実施するようになると。振り返るためには、意味のある活動をしなければならなくなるので、 プランニングや開発の向き合い方が変わってきて、前段の活動も導入されてくるということでした。

ファシリテーション:会議で話題がそれないコツ

1つ目は会議を開く人が「Why」と「Goal」を明確にすることだそうです。 「Why」はなぜ会議を開いたかという理由や経緯のこと。 「Goal」はこの会議が終わったときにどうなっていたいかということ。結論を出しておきたい項目のこと。 この2つを会議が開催される前までに、共有しておくことで、 自分の発言が「Goal」に到達することに寄与しているかどうかわかるようになります。

会議前に共有しておくだけでなく、会議中にも常に見える位置に置いておくことは大事かと思います。

それでも、別の話に飛ぶことはあると思います。 それ自体が悪いことではないと思いますが、 決められたタイムボックスの中でGoalに到達できないと、 何のために集まったの?ということになってしまいます。

自分も含めてですが、 別の話に飛んだときはついついその話で盛り上がってしまいます。 (別の話に飛んだということは、飛ぶだけの理由があったはず)

二つ目は、議題に合っていないことを視覚化するということだそうです。 例えば、ホワイトボードなどを使って、 議論にあっている内容については真ん中に大きく書く。 議論にそぐわない内容や余談については、端のほうに書いたりすることで 話している人と参加者がGoalに寄与していないことがわかります。

ファシリテーション:時間いっぱい使われてしまうときは

会議でとにかく2時間いっぱいいっぱいつかって時間切れで着地風?みたいに終わることがあります。 先に述べたさんざん会議で話題をそらせた結果こうなってしまっては元も子もありません。

この対策も時間の視覚化や、残り30分になりましたので、Goalに向かっていってください。 というような仕掛けを作ることで改善できるようです。

ファシリテーション:意見がでないときは

誰も意見がないときは、自分で意見を言ってさらに意見がでなくて議論が壊れる。みたいなことが起きうるんじゃないかなと思っています。

意見が出ないときは、付箋を使って意見を出してもらうという方法があるようです。 このようにすれば、事前に誰にも見られない空間で一度発言して録音したものを、一斉に出してもらう形になるので、他の人に影響を受けずに出せるというメリットがあります。 強い人に気後れすくことなく?意見を出せるかもしれません。 また、ゲーム感覚という側面もあって、たくさん出したい、ホワイトボード埋めたい!という効果から意見がでるということもあるみたいです。

あとは、出た付箋をつつくだけ?で意見のある会議になるみたいです。

その他のキーワード

エリック・エヴァンスのドメイン駆動設計 3章輪読会に参加して

引き続き参加してきたので、備忘録を

ddd-community-jp.connpass.com

今回は学びもありましたが、共感のほうがおおかったので、事前に自分でまとめたことを文章化しておきます。

ドメインと実装両方の目的に使える単一モデルを要求すること

なぜ必要か?

ドメインと実装両方の目的に使える単一モデルを採用しない場合、ソフトウェア開発をすすめていくと以下のようなことが発生します。 - ある程度の活動の後の、分析活動や分析モデルは、設計モデルと一致しないため、ドメインの重要な概念であったとしても設計モデルに取り入れられない - ある程度の活動の後の、設計活動や設計モデルは、分析モデルと一致しないため、ドメインの重要な概念を失いながらモデリングされる

エヴァンスの言葉では以下のように書かれています

分析と設計の間に致命的な亀裂が生じるため、それぞれの作業で得られる洞察は互いに活かされることがないのだ(p46)

分析・設計モデルを互いに考慮しないということが、互いの活動で発見したドメインの重要な概念の欠損を起こし、ドメインとソフトウェア実装の乖離が大きくなります。 結果として、結果としてバージョンアップ・保守を行う際には、

ドメインを理解し、 ②実装を理解し、 ③ドメインと実装の変換を思案し、 ④ドメインと実装に不整合が起きないか?

ということを考慮して実装しなければならなくなります。また、副次的に以下の作業も発生します。

ドメイン分析の資料を作成し ②実装を図示し ③分析から実装に落とし込む変換内容を図示し ④既存機能の入念なテスト

ドメインと実装両方の目的に使える単一モデル」どのような活動か?

モデル駆動設計は、分析モデルと設計という二分法を捨て去り、両方の目的に使える単一のモデルを探し出す。...そのため、我々は選択したモデルに対する要求をもっと厳しくしなければならない。そのモデルは全く別々の2つの目標を満たす必要があるからだ。

ドメインを抽象化する方法は常に数多く存在し、アプリケーションの問題を解決できる設計も常に数多く存在する。だから、モデルと設計をむずびつけることは現実的に可能なのだ。

コードはモデルのひょうげんとなるから、コードに対する変更はモデルに対する変更になるかもしれない。実装を一分の狂いもなくモデルに結び付けるには、通常、オブジェクト指向プログラミングのようなモデリングパラダイムをサポートする、ソフトウェア開発のためのツール言語が必要である。
(p47)

イメージにすると以下のようになると考えました。

f:id:mametarou963:20200927111054j:plain

初期設計時の活動は以下のようになると考えました。 - 分析により生成するモデル群はたくさんある - 設計により生成されるモデル郡はたくさんある - 両方を満たすモデルは必ずある。両方を満たす一つのモデルを探索する - 探索したモデルを忠実にコードに落とす。モデルを忠実にコードに落とせるように、オブジェクト指向などのサポートがある言語を選択する

また、開発中・バージョンアップ・保守時の活動は以下のようになると考えました。

  • [実装時に得られた知見]モデルに影響を与えるようなコード修正が発生した場合(※typoとかじゃなくてってこと)、分析・設計モデルも同時に見直すこと
  • [再分析時に得られた知見]モデルに影響を与えるような分析知見が得られた場合、設計モデルとしても耐えうるモデルを再生成し、再度コードに忠実に落とし込む
  • [再設計時に得られた知見]モデルに影響を与えるような設計知見が得られた場合、分析モデルとしても耐えうるモデルを再生成し、再度コードに忠実に落とし込む

つまり、上記のイメージを維持したまま開発を勧めるということかなと考えました。 これらを行うことで、分析・設計・コードが単一モデルを参照できるようになります。 参照箇所が一か所であるということは、そのモデルが変化・表現できる範囲であれば、 コスト安で拡張・保守できるということになると思われます。

これらの活動達成のために何が必要か?

  • 分析、モデリング、設計、プログラミングは同じ人がやること
    • 分析、設計、プログラミングは各フェーズで共通のモデルに影響を与えうるフィードバックがある。これらを分断してしまうと、先のイメージ通りのモデルとコードが維持できない
  • モデルを忠実にコードに落とし込めるソフトウェアサポートがあること(オブジェクト指向

ドキュメントの削減とドメインの概念の維持の効能

いろいろな書籍に何をドキュメントとして残すか?という話が出てきますが、共通項としてはコードに表現されていないことかなと思います。

分析と設計が分断されたソフトウェアの場合は、以下のドキュメントが必要になります。

ドメイン分析のドキュメント ②分析と設計の紐づけのドキュメント

しかも、設計時に出てきた問題を分析に持ち込めない結果、文章として表現できなくなり、相互参照できなくなり最終的にメンテナンスされないところまでが見えます。つまり文章量は多くなり、メンテナンスはされないという残念な結果になりそうです。

一方、理想的に「ドメインと実装両方の目的に使える単一モデル」が選定されていて、「モデルが忠実にコードに落とされている」場合、ドキュメントは格段に少なくなると考えます。 具体的には、コード自体がモデルを表現しており、モデルが設計と分析の側面をきりとっていますので、極論を言えば、ドキュメントには「なぜ」該当ドメインをそのように分析して「モデル」を生成したかが残ってれば十分ということになるかなと思います。設計のモデルについては、分析モデルと共通項を探したということで説明がつくため省略できる可能性があるかなと思いました。

エリック・エヴァンスのドメイン駆動設計 2章輪読会に参加して

前回に引き続き参加してきましたので、備忘録を。

ddd-community-jp.connpass.com

前半はユビキタス言語、後半はモデルとは何ぞや?という話だった

ユビキタス言語について nrsさんが以下のように言っていて、すごく納得感があった。

まったく違うものを同じ名前で呼んでた→コンテキストを分ける
まったく同じものを違う名前で呼んでた→同じ名前にする
まったく同じものを同じ名前で呼んでた→素晴らしい
まったく違うものを違う名前で呼んでた→素晴らしい

何が起こるかというと、名前を呼べば、2者が同じものを浮かべるので、齟齬がなくなること。 会話の中でも、モデルの中でも、実装の中でも齟齬がなくなればそればとても素晴らしい。 ユビキタス言語大事。

あと、議論の中でユビキタス言語が周りに説明できないからいい日本語の言い回しないか?という話がでましたが、 ユビキタス言語をそれ以外の言葉を使うと、ユビキタス言語自体に揺らぎがでるので、ひたすらユビキタス言語という言葉を使うことによって習慣から文化で飲み込んでいくしかないのかなと思ったり。

モデルの定義

そもそもモデルってなんだろう? 第2章を読んで質問をひとつだけあげるならこれでした。

輪読会でも取り上げていただいてたので、大変助かりました。が、油断して晩御飯食べている間に盛り上がっていたので惜しいことをしたな、と。

モデルは図ではない
  - 忘れがちなので、常々意識したい
  - ただ疑問が生まれた(モデルとは

モデルとは何ぞや? ここで適当にぐぐって答えを探したくなりますが、little_handsさんが

「モデル」って、全世界で意味が統一されているわけではなく、文脈によって全然違うものなので、
DDD輪読会としてはDDD文脈の定義を正とするのが良いと思っていまして
その定義がevans本末尾の用語集か、DDD Referenceの定義を正とするのが公式採用という意味でいいかなーと思ったりします

という話をしてくださっていて、なるほどなと。わけわからない表現ですが、ドメイン駆動設計のドメインではモデルの定義はevansが定義したものを正としましょう。ということです。 ググればモデルの説明はたくさんでてきますが、それはDDDとは別のドメインで語られているモデルの説明の可能性が高いということなのかなと思いました。

そうじゃないと「僕はこれがモデルだと思います」の決闘!になっちゃうので笑

では、Evansは何と言っているかというと

モデル:
ドメインにおける選択された側面を記述し、そのドメインに関連した問題を解決するのに使用できる抽象の体型

公式リファレンスでは

問題解決のために、物事の特定の側面を抽象化したもの

となっています。 ので、この言葉がモデルの定義であり、この言葉が腑に落ちれば、 モデルを理解するということになるのだと思います。

DDDにおけるモデルの定義を理解仕様とする試み

DDDにおけるモデルとは

問題解決のために、物事の特定の側面を抽象化したもの

ということでした。つまりなんなのかと。 思って、少し具体例で考えてみようと思いました。 ここで、気を付けたのは「何であって」「何出ないか」という視点で書いています。これも一つの抽象化なのかもしれませんが。。。

個人的な意見ですが、言い換えると、あるものごと(ドメイン?)があって何か問題解決をしたいときに問題解決に必要でないものを排除し、問題解決に必要なものを取り出し、その取り出したもの同士あるいは、問題解決の関係性を示すとも言えるかなと思いました。

あまり良い例ではありませんが、子供の手押し車があったとします。 この手押し車は物体として存在するので、縦横高さ、素材、形状、金額などが存在しています。

このとき、「ある子供」はこの「子供の手押し車」を使う体形にぴったりかどうか?という問題を取り扱うドメインがあった場合

  • 問題解決に必要でないもの:金額、素材、形状
  • 問題解決に必要なもの:縦横高さ
  • 取り出したもの同士あるいは、問題解決の関係性:子供の身長より縦が小さいか?,横幅は大きすぎないか?など

雑ですが、上記のように様々な手押し車を上記の側面で抽象化すると、その子供か扱えるかどうかがわかります。 すなわち、「問題解決のために、物事の特定の側面を抽象化したもの」になっている。と考えます。 一方、別問題である「子供にとってこの手押し車は安全か?」「予算内でこの手押し車は買えるのか?」などの解決には寄与しません。

また、別のドメインとして「人間」(※大人も含む)がこの「子供の手押し車」は生活の中で安全か?という問題を取り扱うドメインがあった場合は、状況は異なり以下のようになると考えます。

  • 問題解決に必要でないもの:金額、縦横高さ
  • 問題解決に必要なもの:形状、素材
  • 取り出したもの同士あるいは、問題解決の関係性:素材が発がん性があるものかどうか?、形状の角がとがっているかどうか?

雑ですが、上記のように様々な手押し車を上記の側面で抽象化して基準値を設けておけば、「人間」(※大人も含む)がこの「子供の手押し車」は生活の中で安全か?ということがわかります。 すなわち、「問題解決のために、物事の特定の側面を抽象化したもの」になっている。と考えます。(2回目) これも、別問題である「使う体形にぴったりかどうか?」「予算内でこの手押し車は買えるのか?」などの解決には寄与しません。

つまり、当然のことかもしれませんが、同一の物事に対して、「解決したい問題」が変われば、モデルは変わるということになります。言い換えると、物事をそのまま、考えや絵やコードに落とすことはDDDの世界ではモデルではないということになります。

次にモデルは絵なのか問題?

個人的結論を述べておくと、違うと思っていて、議論の中でも違うという意見が多数派だったと思います。 以下のコメントが刺さりました。

なんとなくだけどモデル = オブジェクト図って固定観念からスタートしてしまっていると混乱してる気がする

まさにその通りで、くどいですが、Evansの定義を再掲すると

問題解決のために、物事の特定の側面を抽象化したもの

モデルは抽象表現である。ということになります。 そして抽象表現は文章でも図でも絵画でもいいはずです。

クラス図も、目的を持った抽象化物なんでモデルの一種ですうよね
モデルに、図も、文字列も、含まれると思います
現実世界を抽象化して表現するときにどういう手段を使うか、という話で、それは図かもしれないし文章かもしれない

その通りだなと思いました。

2つのモデルがあったとき(例えば片方が文章で片方がオブジェクト図)に以下の可能性があると考えます。 ①同じ問題解決のための、別の表現 ②異なる問題解決のための表現

業務の中でも同じことを書くけど、絵のほうが伝わりやすい箇所は絵で、文章で列挙するところは列挙して必要ならどちらも、みたいな選択はすると思いますが①はまさにそれかなと思いました。

同じ問題領域だけど、モデルの表現方法はたくさんあって、それは受け手によって使い分けなければならないということなのかなと。

最後に刺さったコメントを列挙して、また3回目に挑みたいと思います。

「モデル」と「モデルの表現」は違うという話、仰る通り
「モデルは見えない」っていうのは凄まじく同意しました
触れられないものがあるのは非常に共感を持てます
その上で、それはモデルではないと思ってますー
それをなんとかして表現しようとしているからモデル(模型)だと思ってます

M5StickCで自動で水中ポンプを制御する

背景

前回、水中ポンプでM5StickCで制御できたので、次はデパートみたいに手を出すと自動で水がでるようなものを作りたいと思いました

mametarou963.hatenablog.com

準備物

組み立て

前回のものから、PIRハットをくっつけるだけです

プログラム

UI-FLOWを使うと以下のようになります f:id:mametarou963:20200823224338p:plain

動作の様子

youtu.be

www.youtube.com

感想

デパートのようなタイミングで水が出て満足しました。

M5StickCで水中ポンプを制御する

背景

前回、水中ポンプが動いたので、 M5StickCで制御したくなったのでやってみました。 mametarou963.hatenablog.com

準備物

f:id:mametarou963:20200823221608j:plain

組み立て

ミニリレーユニットに水中ポンプとUSB切りっぱなしケーブルをつないでリレーで制御できるようにつなぎます

f:id:mametarou963:20200823221617j:plain

プログラム

UI-FlowでM5StickCでのボタンを押すとリレーをたたくだけのものなので非常に単純なので省略します

動作の様子

youtu.be

感想

小学生のような感想ですが、水の制御は実際やってみると思ったより楽しかったです。 次は人感のタイミングで水を出すと、デパートのトイレとかと同じことになるかと思いますので、やってみたいと思います。

エリック・エヴァンスのドメイン駆動設計 1章輪読会に参加して

輪読会に参加してきました。 ddd-community-jp.connpass.com

刺さった言葉と自分なりの理解ををメモ書き程度に残しておきます。

ドメインとは?

議論の中で以下のコメントが出てきて、いきなり刺さりました。

モデルもそうだけど、ドメイン自体も定義が必要

そもそも日本語化難しいので、自分の中で消化しようとしてあきらめてチーム内でもドメインという言葉で無理やり解決していました。議論では以下のようなものがありました。

  • (ソフトウェアの)ドメインの意味
    • ユーザーの関心・活動
    • すべてのソフトウェアプログラムは、それを使用するユーザの何らかの活動や関心と関係がある。ユーザがプログラムを適用する、この対象領域が、ソフトウェアのドメインである。(エリックエヴァンスのドメイン駆動設計より)

ドメインはプログラムを適応する対象領域であり、どんな対象領域かというと、ソフトウェアプログラムを使用するユーザの何らの活動や関心と関係がある。

例えば、部屋の予約受付システムの場合、どうやったら部屋の予約がとれるか現在の部屋の予約状況は?予約をキャンセルするにはどうすればよいか?などが活動や関心になると考えます。 上記の部分が、プログラムを適応する対象領域、すなわちドメインというと理解しました。

また、議論の中で、

「ドメイン」を別の単語に置き換えようとすると混乱の元な気がします

というコメントもありました。置き換えれれば、ドメインではなく、日本語で広まったのでしょうが置き換えられないからドメインのまま広まっているのかもしれません。ある程度ドメインのイメージを自分の中で消化したうえで、ドメインという言葉を使っていこうと思います。

また、上記で懸念されるのが、自分の言っているドメインと相手の言っているドメインの意味に齟齬がある場合があると思われるので、気を付けて話をしたいと思いました。

ドメイン設計とドメイン駆動設計の違い

(エヴァンス本では)ドメイン設計とドメイン駆動設計は明確に別の意味で使ってるように読める
ドメイン設計は、ドメイン駆動設計でなくても必要だと思ってます

この発言はかなり衝撃で意識したこともありませんでした。 ドメインドメイン分析ドメイン設計ドメイン駆動設計をそれぞれ定義しないと後の話についていけない!という焦りがありましたが、議論の中でその答え(一例?)を書いてくださっていました。

ドメインを分析して、ドメインのあるべき姿を設計するということ。
ドメイン駆動設計は、ドメイン設計を通じて構築されたドメイン知識に基づいて
定義されたモデルと実装を一致させていこう、というアプローチだと理解してます

そして、そうなると分析と設計ってなんだ??ってなり、分析設計でググってみると、エヴァンス本のQiita記事が上位にヒットしたのでありがたく拝借し、整理してみました。

エヴァンス本、輪読会、上記の記事を合わせ考えると、私の中では以下のような整理になりました。

項目 解釈
ドメイン ソフトウェアプログラムを使用するユーザの何らの活動や関心と関係がある領域
ドメイン分析 ドメインに関する問題領域を明確にする作業
ドメイン設計 ドメインに関する問題領域の解決策を導く作業
ドメイン駆動設計 ドメイン設計を通じて構築されたドメイン知識に基づいて、定義されたモデルと実装を一致させていく活動のこと

ドメイン駆動設計ドメイン設計に依存し、ドメイン設計ドメイン分析の精度に依存することがわかりました。なので、しっかりとしたドメイン分析なくしてドメイン設計はありえず(ドメインが明確になっていないのに、ドメインの解決策は出せない)、ドメイン設計なくしてドメイン駆動設計はありえない(ドメイン設計ができていなければ、ドメイン知識ができていないため、それに基づいた実装もできない)。

つまりソフトウェアつくる人はしっかりドメイン分析しろと。

私もやっていなかったわけではなかったですが、それは業務の一部というようなとらえ方でしたが、この考え方でいけば、すべての土台と考えられるような気がします。

そして、この考え方はエヴァンス本では以下のように書かれています。

ソフトウェアの核心は、ドメインに関係した問題をユーザのために解決する能力である。
それ以外の特徴はいずれも、どれほど重要だとしても、この基本的な目的を支えるにすぎない。
ドメインが複雑だと、ドメインに関係した問題を解決するのは難しい作業になり、
熟練した有能な人々が集中して取り組まなければならなくなる。

私なりの意訳: ソフトウェアの真の目的は、ドメインの問題領域を解決することです。

開発者はビジネスの知識を積み重ねるべく、ドメインに没頭しなければならない。

私なりの意訳: ドメインの問題領域を解決するためには、しっかりとドメイン分析して

モデリングスキルを研ぎ澄まし、ドメイン設計に精通することが要求される。

私なりの意訳: それに基づいて、ドメイン設計しないと駄目だよ

前よりは少し理解できた気がしました。

ちなみにエヴァンス本の続きは、耳が痛い話で、

しかし、たいていのソフトウェアプロジェクトでは、ドメインに関係した問題の解決が重要視されない。
有能な開発者のほとんどは、自分の手掛ける特定のドメインについては勉強する気があまりなく、
ドメインモデリングのスキルを真剣に伸ばすつもりはさらにない。
技術志向の開発者は、自分の専門スキルを発揮できる、定量化可能な問題を楽しむものだ。
ドメインに関する作業は面倒なうえに、入り組んだ新しい知識を大量に必要とするが、
そうした知識は開発者にとって、コンピュータ科学者としての能力を向上させるものではないように見えるのだ

私なりの意訳: ほとんどの開発者はドメイン分析ドメイン設計に興味はない。 なぜなら、これらの作業は開発者の本業じゃないと思っているし、楽しくないし、スキルが発揮できないし、スキル工場にもならないと思っている。

これが本当だとすると、

ソフトウェアの核心は、ドメインに関係した問題をユーザのために解決する能力である。
それ以外の特徴はいずれも、どれほど重要だとしても、この基本的な目的を支えるにすぎない。

にあるように、ソフトウェアの核心部分をおざなりにして、基本的な目的をささえるものに熱をあげているということになります。結構ショッキングでしたが、肝に銘じました。

ドメインとビジネス,業務知識の違い

「ドメイン知識」と「業務知識」も、また not equals なんじゃないかと最近思い始めてたり
ドメイン知識 == 業務知識 だとしたら、最初から「業務知識」って書きますよね

この辺りはまだ自分にはよくわかりませんでしたが。

gitやsvnのドメインは、雑に言うと「バージョン管理」になると思いますが、それはいわゆる「ビジネス」とは呼ばれませんよね
業務ソフトウェアだけがソフトウェアではないし、すべての人がビジネスにしか興味がないわけでもない

は後々納得感を助けてくれると思いますので、書き残しておきます。

ドキュメント残す、残さない問題について

完全に私の意見ですが、 仮に、ドメイン設計およびドメイン駆動設計によりコードなどの落とせたと仮定して、 解決領域のみが成果物に落ちる形となると考えました。 そうなると、問題領域、つまりドメイン分析部分となぜ、そのドメイン設計を選択したか?という情報については成果物には残らないことが予測されます。 なので、これらの部分は、ドキュメント人の伝承成果物に添えるコメントなどで補っていかないと、何に対する解決なのかというものだけが残ってしまい、成果物から問題領域を予測したり、設計の意図を探っていく作業が発生する可能性があると考えました。

輪読会に参加しての感想

  • 進行役2名、解説や意見いう方1名で、すすめていましたが、大変バランスがよく聞きやすかった
  • ddd界隈で有名な方々が多数参加していてよかった
  • 有名な方々がいる中でも、すごい贔屓するわけでもなくバランスよく意見を拾っていてよかった
  • タイムキープがすばらしい。終わりがわかっているから集中して聴ける。少し伸ばす場合でも理由を宣言しているので、納得感があった
  • 程よく参加者に参加しやすい空気感をつくってくれている。参加してもいいし参加しなくてもいい。そして参加してくれると喜んでくれていたので、参加しやすかった。ちょうどFMラジオのような感覚

エリック・エヴァンスのドメイン駆動設計 1章を読んで

ddd-community-jp.connpass.com

上記のイベント参加前に「エリック・エヴァンスのドメイン駆動設計 1章」を読んでの殴り書きです。

活動のサイクル

  1. 開発者が(現時点で描ける)ドメインモデルを作成する
  2. ドメインエキスパートを含めたプロジェクト関係者と話す。話す内容は以下の通り
    • 現在着目しているシナリオ(つまりユースケース?)にドメインモデルが適合しているか?
    • ドメインモデルあるいはシナリオで登場する言葉に違和感はないか?
    • 不要な概念はないか?
  3. 結果を整理し、最初に戻る

現在着目しているシナリオにドメインモデルが適応しているか

  • 筆者の環境ではドメインモデルが書いてある資料を見て、その製品の有識者が「このパターン忘れてない?」「こんなときはどうするの?」という発言がそれに当たると考える

ドメインモデルあるいはシナリオで登場する言葉に違和感はないか?

  • そっちでは「XX」って書いてあるけど、普段は「YY」って言っているやつねという発言がそれにあたると考える
  • 2章をチラ見したら熱く語られている。とにかくばらばらの言葉を使っているとコストがあまりにも高くつきすぎる

不要な概念はないか

  • ドメインモデルが書いている資料をみて、設計者・有識者が「そのクラスいる?」「なんかかぶってない?」という発言がそれに当たると考える
  • 筆者の例では、以下のようなことがあった

電源制御のコンテキストの中で停電が発生した際のシステムのふるまいをモデリングしていた。 具体的には、停電発生時に、UPSが落ちきる前にシステムを安定状態に持っていくというものをモデルに入れていた。 しかし、電源制御なので、電源周りを責務するはずで、

  • 内外部の状態、指示に応じて電源をONしたりOFFしたりする
  • 電源の現在の状態を通知にしたり、要求に対して応答したりする

以上のことを実施するとおかしいという指摘が入った。 結果としてシステムを安定状態に持っていくのはシステムがわのコンテキスト側でモデリングし、 電源制御はUPS時間待機し、システムの安定状態を受信するか、UPS時間が満了した場合に電源を落とすというモデルに変更した。これで、モデルはすっきりし、電源制御の役割も明確化した。完ぺきではないかもしれないが、エヴァンス本でのモデルの蒸留(不要な概念の排除)を体験した。

所感

  • エヴァンス本にでてくるドメイン・エキスパートがミーティングに積極的だなと思いました
    • エリック・エヴァンスのドメイン駆動設計 輪読会 1回「序文、目次、索引」でも話されていましたが、ドメインエキスパートが近くにいなかったり、捕まらなかったりしてこれが実現できない現場はあるだろうなと
    • ここでは省略されていますが、ドメイン・エキスパートを据えることが設計・開発プロジェクトにとってどれだけ重要であるがということが共有されていないと難しいと感じた
    • 逆に、エヴァンスの例やDDDが実践されている組織はその認識が持てるような工夫があるのかもしれない