ドメイン駆動設計のススメ～組織にDDDを適用する～がすごく良かった！
今日の積み上げ
AWS学習
今日は結構頑張って、WEB問題集の２周目まで完走した。
９割を超えてるので、だいぶん知識として定着してきた感はある。
自信を持って回答できない問題も特定できてきたので、しっかりと復習していくことがこれからは大事そう。
明日は間違えた問題や苦手サービスに関する問題を集中的に取り組んでみよう。
そうそう、昨日ブログに書いた、AWSではじめるデータレイク: クラウドによる統合型データリポジトリ構築入門、無事社内経費での購入を認めてもらえた。
機械学習の輪読会にも参加することだし、データ利活用分野の知見も今後増やしていきたい。
英語学習
４日目の音読は、0.90倍速に挑戦。
昨日がっつりやったおかげで、かなり口が回せた。
オーバーラッピングもところどころ詰まるとこはあるものの、だいぶんスムーズに発音できるようになってきた。
明日からはシャドーイングに挑戦していくゾ！
ドメイン駆動設計のススメ
この「ドメイン駆動設計のススメ」の動画シリーズ、過去動画も視聴させていただいたが、個人的には今回が一番面白かった！
＜ドメインモデルの粒度問題＞
これまで自分が歩んできた実体験からも、大規模開発でのドメインモデルの粒度問題は本当に関係者間で合意をとるのが難しい。
この部分は、加藤潤一さんが「認識問題：共通了解の領域と共通了解不成立の領域」のスライドで解説されていて、「たしかに！」と膝を打ちたくなってしまった。
ちなみに、共通了解の領域と共通了解不成立の領域はスライドでは下記のように紹介されています。
- ＜共通了解の領域＞
- 自然科学、数学、基礎的論理学
- <共通了解不成立の領域＞
- 感受性・審美性、価値観、宗教、人間観・世界観
話をドメインモデルの粒度問題に戻すと、特に、複雑な業務処理になればなるほど、その難易度は高いのは間違いない。
なのに、柔軟な変更に対応できない硬直した組織の壁に阻まれてしまい、洗練されていないモデルのまま突き進むしかない状態に陥る、というお決まりのコースを歩んでいきがちだ。
ウォーターフォール型でドメイン駆動設計をやっていくより、そこはやっぱりアジャイル型でやっていく方が相性がよいというのはその通りで、あとはそうした開発スタイルを採用することを組織にどう受け入れてもらえるか、という話になりそう。
＜アーキとアプリの関係性＞
そして、この動画でもう１つ興味深かったのが、「アーキテクチャチームとアプリチームの関わり方」に関する宇賀神さん（しょぼちむさん）のスライド。
どちらかのチームに権力があるかのような関係は失敗パターンとのこと。
これも実体験として、すごくよくわかる。
アーキテクチャチームから「これに沿ってやってね」と言われるものの、それがまぁ使い辛くてしょうがない代物で、開発の足かせになっていくパターン。
彼らは良いものを作った自負があるのかもしれないが、しょせんは業務を分からない人達が作っているという悲しさ。。
アーキテクチャチームにせっかく優秀な人が集められても、ボタンの掛け違い（認識の不揃い）があるばっかりに、お互いのチームの良さが活かし合えていない。
では、成功パターンとは？
２つ紹介されていた。
１つ目は、アプリチーム内で適切なコミュニケーションを取り合いながら、構造（ドメインモデル）を生み出していく（作っていく）こと。
２つ目が、アーキテクチャチームが上でアプリチームが下という関係性ではなく、アプリチームを重視する（尊重する）アーキテクチャチームを作っていくこと。
なるほど。
こういう認識がお互いのチーム間で共有されていれば、プロジェクト内の雰囲気もよくなって、より良いものが生み出せそうな気がする。
ドメイン駆動設計を組織に適用する意味を改めて考えさせられる、本当に素晴らしい動画だった。
それでは、また。
