前回ひ引き続き、DDD輪読会に参加しました。
今回は、聴きながら家のことでバタバタしており所々でしか聞けませんでした。 Discordeの参加者のみなさんのコメントを後追いして、ピックアップします。
前回の勉強会のメモ restofwaterimp.hatenablog.com
今回も前回同様、事前にhackMDに気づきや疑問を記載し、それを拾い上げるスタイル。 前回と違うのは、気づきの数が・・・倍以上に膨らんでいる。
今回、一番刺激になったのは本編ではなく、本編終了後の廊下でのミノ駆動さんの話。 そこに至るまでの前振りなどは背景がわからないので、私の中では？？？なのですが、 evans本の本質、というかエリック・エヴァンスが伝えたいこと。というのに立ち返れた気がします。 内容は後ほど。
また、本勉強会で前回も感じたのですが、みなさん「言葉の定義」に敏感。 自分が気にしてなかったことも、取り上げられて議論されるので、それを聴ける、見れるだけでも勉強になります。
学び(完全に自分のためのものです・・・hackMDのコメントを拾って、リンクなど)
今回聞いたところのhackMDから自分がわからないこと、深堀したいことをピックアップ。 この記事で何か学べるわけではありません。自分もここからリンクを追って、学べるようにまずは書き起こしてます。 これから、参加していき、何のことか自分なりで語れれば、更新していきます。 深く学びたい場合は、勉強会へ参加するのが近道ですww
参加されている方の属性(しばてぃさんがPower BIで作成したもの。こういうことがすぐできるのが、 Power BIの凄さですね) オンラインということもあり、全国から参加されてます。
例の「Power BI でリアルタイムアンケート」を evans 輪読会の勉強会でやってみた！
— { "しばてぃ" : "Takashi Shibata" } (@shibatea365) 2020年9月5日
非常にウケが良かったのでまたやってみたい！#dddcj pic.twitter.com/hKHFEJnOtR
2章のHackMD
「用語と概念間の関係性」
この意味と、表記の揺れや意味の揺れについて議論が進む。 開発者とユーザ側。また、ユーザの間でも意味が違う。 コンテキストが異なれば、意味が違うのはそうなのだろうが、同じコンテキストないで、同じ意味を違う言葉で使っていたり、同じ言葉を違う意味で使っているなら統一する必要がある。
「よく言われる「DDDは重厚・重たい」という評価の発祥はどこか」
私は重たいと思っていた。書籍の厚さもあるが、覚えなければいけないことがたくさんあるイメージがあった。 実際、最初に一人で読み始めたときは話が抽象的で、読むために必要なバックグラウンドが掴めていなかった感じ。
実装の本かと思えば、設計の本とも思ったが、どうも単純な設計の話だけに終わらない本というのが今のところイメージです。 読み進めたら変わるかも。
「ユビキタス言語」
little_hands こと松岡さんの
「ubiquitous = in every where」で、ただ言葉を合わせましょう、以上に「会話でも、コードでも、ドキュメントでも」っていう意味が込められてるので、「共通言語」以上の意味を持つのだと思います
で、ユビキタス言語って、文字に起こした時の言葉だけじゃないのねと理解した。てっきり、用語だけ統一と思っていたので。
「OOUI」
オブジェクト指向UIは読んだことがないからどういうことかわからなかったが、フロントエンジニアとバックエンドのエンジニア間で共通の言語を用いた方が良いかという質問かなと。
同じ方が良い意見もあるし、違うこともあるという意見もあった。 私自身の経験だと同じ方が良いという認識であった。が・・あくまで、「開発者の中」という意味で。 これが、ユーザ(扱う部門が違う)とかだと同じデータでも違う言葉を使うこともあるなと思っていたので、何が良いかはわからず。 もし違っていても、違った意味で使っていると関係者が認識できているのならそれはそれでいいのではと思ったり。(ただ、誰かが確認を取らなければいけないので後々面倒になりそう)
「表現すべきことをより簡単に言う方法を見つけ、その新しい考え方を図とコードに再び反映させること」
イテレーティブにすることというのもあるが、社内のコンサルタントによく言われることがあったなと思い出した。簡潔にかつ具体的にわかるかつストンと腹に落ちる言葉を考えるってこと。それを図とコードに再び反映させるってのはドメインのモデルを見直すということ(と自分は認識)
「çになってしまうと、ドキュメントはプロジェクトの進捗とのつながりを失ってしまうことが多い」
この話、リアルで聴けていないのでコメント見て。 いろいろ参考にしてよいというリンクが貼っていたので、転記 前回の知識を噛み砕くでもドキュメントの話は上がっていた。前回はリバースで作れるものはあえて書かない。「なんでそういうモデルにしたのか」というのは残した方がいいよねと。今回の話はドキュメント更新されないよね・・・ということかな？
www.slideshare.net
以下の言葉の定義について議論されていた。
- モデル
- 図
- コード
- ユビキタス言語 自分なりの説明ができると良さげ。
「P41 の図2.4と図2.5 のモデルについて」
違う図が書いてあるのはみなさん許容されている。違う視点で書かれているから。 その事象をどう捉えるかということと、「誰に伝える図」なのかがポイントかなと感じた。
何か調査をするときなども、「自分の分析のための図や表」と「誰かに説明するための図や表」は違うことがある。 また、切り口も変えることがある。
松岡さんが書いていたエリックの地球儀の話はこのyoutubeなのかな？あとでみよっと。 www.youtube.com
ここで22時ちょっと過ぎくらい。ここから廊下が始まった・・(終わったのは翌日2時少し前くらいだったそうです)
上段に記載しましたが、本編外でご講演(?)がミノ駆動さんよりあったので、そこがとてもためになった。 RailsとDDDの話の前提として以下のことが語られました(自分の理解なので間違っていたらごめんなさい)
「DDDで達成したいこと」は何か？という問いかけ
日本語版への序文にEvans自身が書いていて
主人公はコアドメイン。コアドメインの価値を最大化すること。 → メイン業務のウリや価値って何かを語れるか。
ビジネスの足を引っ張るのは何か
コアドメインに集中するために、他の層との結合を疎にする → 例えば、オニオンアーキテクチャ
ドメインの変化 → 実装のモデルも変化
設計時にはコアドメインの変化が実装にどう影響するかはわからない(というか、ユーザとかはしらない) そのため、できそうと設計時に判断してもシステム側が足を引っ張ってしまい、開発生産性が下がり、市場競争に負けてしまう可能性もある。 それを防ぐため、実装もコアドメインに集中させるため、依存を取り除くようにすべきだろうということ。
自社サービス(対外向けのサービス)を作る人はモチベは上がるが、内向きの仕事やSIなどの他企業の仕事の場合は モチベが上がらないという意見もあったが、それは違うということ。 より良い設計を作ることで、自分の価値をあげ給与に反映や、自社の売り上げに貢献する。 自分自身の価値をあげる活動にする。
DDDの特性として、
保守性
変更容易性
機能性
私の周り(SIer)では自分の書いたコードの設計で、自分の価値をあげようとか、売り上げ貢献に反映する動機でDDDなど より良いコードを書くという人がいないのでエンジニアの方からこういう言葉が出るのが衝撃であった。
設計やコードを洗練するということが自発的になされないことが多く、なかなかつらしのこともある(ただの実力不足？)。
わからないなりにDDDを取り入れようとしているのだが、自分の中のモチベは「保守性」と「変更容易性」 提供している機能にコアな部分の変更を容易にし、ビジネスへの変更をなるべく早く対応できるように変えたいなと。
話を聞いていて、実装をする人も経営のことを知るべきと感じた。 (多分、DDDやろうとしている人はビジネスエキスパートと話をする必要があるので、自然に対象のドメイン業務および 経営は学ぶ必要があるとは思っている) 自分たちが作るものの価値、インパクト、投資対効果などなどを見極めつつ何に注力するかというのを 他人任せにせず、自分で決めれるようになるのいい。
参考で貼られていたリンク
脈略のない文章になってしまいましたが、これで終わり。 今回も、開催していただいた@jnuank_さんありがとうございます。
次回もまた参加しよう！
読む敷居を下げてもらえる本(かなりお世話になってます)
