ドメイン駆動・・・。書籍持っているけど、一人で読み続けられず、挫折し、積読状態になっていたところ、 「オンライン」で開催しているじゃん、と見つけ、参加。
昔に統計の書籍で輪読会には参加したことはあったが、「初学者入りにくい・・・」と思っておりましたが、本輪読会。。最高の学びの場でした。 文殊の知恵最高って感じの内容で、あっという間に3時間聞いてました。
勉強会のスタイルは hackMDで書籍の気づき・感想と疑問を事前に参加者で書き書き。 勉強会中は、hackMDの内容をファシリテーターの方が、まるでラジオを聞いているかのような感じで、題目に対してアテンド。 並行で、Discordにチャットでその時の気づきやアドバイスなどなどが経験者や有識者からひっきりなしに書き込まれるという。 音声はきかなあかんは、チャットは追わなければ・・・とてんやわんやでした。
聞いているだけ、チャットを眺めているだけで、学習できるという素晴らしい場の時間でした。
でもって、あとで、チャットを追ってみよう・・・と取り組み始めているのですが、コメントが多く、追うのだけで大変。 ただ、テキストで追っていくだけで、「そういう話していたな〜」と思い出しやすいです。
学び(完全に自分のためのものです・・・hackMDのコメントを拾って、リンクなど)
今回聞いたところのhackMDから自分がわからないこと、深堀したいことをピックアップ。 この記事で何か学べるわけではありません。自分もここからリンクを追って、学べるようにまずは書き起こしてます。 これから、参加していき、何のことか自分なりで語れれば、更新していきます。 深く学びたい場合は、勉強会へ参加するのが近道ですww
ドメイン
エヴァンスの用語解説では「知識、影響、または活動の領域」 開発するのって、このドメインにある問題を解決したいことを作るのかなと。 why必要として、whatどういう姿になっていたいのか。 howに走らない。何となく、BABOKとかREBOKの話かな？
モデルをシンプルにする
幹と枝葉と思っていた。幹だけを見つけるのがとても難しい。それも、「誰も見ても、それ！」と言える部分を見つけるのが。
コメントで参考となっていたサイト martinfowler.com シンプルなデザインのルール
テストに合格する
意図を明らかにする
重複なし
最小限の要素
優先順位は上の方が高い。 実装する時や設計する時は「意図を明らかにし」「最小限の要素」でドメインのことを示すことができるのか。 不要な部分は削るのだが、削った結果、「ビジネスに価値があるモデル」になっているかかな？検証するには例示とかかかな。
アジャイル開発(大規模)
「チームを複数に分割したアジャイル 開発」→危うい
何となく、モデル分析して、「このモデルはこのチーム」「このモデルはこのチーム」、「かぶるところあるけど、これはあのチーム」って分けるとあとで崩壊ってことかな？ もしくは、全体のモデルを考えずにモデル考えて、全体でつなげたらつながらん・・・ってことかな。SIerだとよくある・・・ってなっていたけど、よくあるかと。 アジャイル でなくても、ウォーターフォールでもあると。関連するシステムの境界を跨いで全体を俯瞰できるように(一人でも複数人でも)しなければ、 ドメインの境界はつながらないだろう。(業務もシステムもどちらも考える必要あると個人的な経験ではかある)SIerだと、先に機能ごとにチーム分けて、 つながらなくなることありますから・・・。
cynefin framework ← 初めて聞いた
知識の噛み砕き
CleanArchitectureから考えるのか？？ モデリング と言ってもデータベースモデリングではない。業務分析/ドメイン分析のこと。 ここは納得。データモデリングからするのではなく、業務を知ること。用語、一番主となるフロー、登場人物などを知ることが先。 また、その業務が「何のために、何を実現させるために」やっているかを整理するのも。(これしないと、データの世界だけで追っていても何作っているのか訳わからなくなる)
「最初からドメインオブジェクトだけをテストコード上で会話させる設計」 → どういうことかわからず。。。。本読めばわかるのかな？
勉強会の参加の皆さんは「設計、分析は一回こっきりではなく、ずっとやる」というtwadaさんのコメントに納得されていますが、 私の周りの現実ではそうならないこと多いなと・・・(業務は常に改善、進化するがね。システム変わらないのかい？というのと、システム作っても「もっと良い感じにならないかな？」 と考えるのが価値を高める気がするのだが・・・)
継続的学習
ここの質問、自分の取り上げてもらえてよかった。ドメイン知識が人に残る(それが成長)というのは理解できていたのだが、一度解散したプロジェクトがまた戻った時、 どうやってドメイン知識を引き継がせるのか・・・がわからなかったので。コードの設計はドメインの切り方などで残すけど、設計意図とかどうやっているのだろうと。
意図や歴史を（口頭でも）伝承できる人を増やす、絶やさないという方向もあったりしますよね は私もなるほどと思った。一人じゃなく、増やせばいいのだと。
why なして、そういう設計(モデル)にしたのかを他でわかるようにしておく what ←
how Resharperやjig(私もC# 使いなので、ReShaper使いたいけど、買ってもらえない・・・)
RDRA ADR(Architectural Decision Records) Design Doc → 聞いたことなかったので、見てみる。 www.sparxsystems.jp
ドメインエキスパートへコードを見せるか
自分は見せたことない。間に入る方(大体情報システム部門)へはありますが・・・。 コードではなく、業務モデリングを見せて説明かなと。そっから、正常系なのか例外系なのかを嗅ぎ分けるのが難しいですけど。 (往々にして、話し手のバイアスが入るので)
ソフトウェアを再構築するようなモデルの見直し
私もこれは気になっていた。放っておきたいけど、メスを入れたいのだけど・・・
t_wadaさんより t-wada.hatenablog.jp
で、タイムラインに流れてきたこれをポチりとした。
きたら読み込む
リファクタリング、リアーキティング、リライト について書いてあるそうなので、そこをまずはみる。
輪読会で扱っている書籍
