Actier COO なブログ

株式会社アクティアのCOO（くぅ〜）による「くぅ〜！」と思って貰えるような何らかを提供していきたいブログ

Gunma.web にドメイン駆動設計で遠征してきた 〜ドメイン駆動設計は「男の料理」

勉強会 DDD 登壇

2018/1/20 に Gunma.web #30 という勉強会に遠征してきました。

f:id:k_takasaki:20180206000018j:plain

 こんな感じのおしゃれな喫茶店の 2 階で開催されました。

Gunma.web とは

WEBサイト作成に関わる人が集まる勉強・研究・交流の地域コミュニティです。
WEBサイト作成に関わる プログラマー、SE、HTMLコーダー、WEBデザイナー さんなどが集まります。

東京や関西で　webサービスに関わる人が集まっての研究、懇談会が行われ、WEBサイト作成のスキル、意欲向上の大きな手助けとなっています。

群馬県でも地元の技術者、サービス関係者を集めWEBサイトの作成スキル、意欲向上の手助けになればと思い開催しています。

といった群馬の web 系勉強会 & コミュニティです。
2010 年に第 1 回目を実施され、今回が 30 回目というかなり長いこと継続して活動されている勉強会です。

遠征の経緯

今回、Gunma.web #30 のテーマとして、DDD「ドメイン駆動設計」を扱いたいとのことで

といった感じで、Gunma.web を主催されている @kanayannet さんから、DDD Alliance にツイッターでお声がかかりました。
基調講演でゲストとして誰か話に来てくれないかといったお誘いです。

DDD Alliance は、

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

 

を書かれた有限会社システム設計の増田さんと、株式会社アクティア、そら製作所、井上屋で立ち上げたドメイン駆動設計の実践経験を基にしたワークショップやオンサイトワークショップ、コンサルティングを展開しているコミュニティです。*1

ドメイン駆動設計をシステム開発の現場で活用することにお悩みの方々の一助になればと日々活動している団体なので、こちらとしてもぜひ！とゲストのお誘いにのって増田さんと僕で遠征してくることになりました。

発表内容メモ

「基調講演＋LT＋懇談会」といった構成で、非常に盛り上がった勉強会でした。
メモ形式＆ちょっと感想等（※ 部分）を入れつつ、各発表の内容をまとめてみます。
あ、自分の発表だけは解説っぽい感じです。

基調講演「ドメイン駆動設計とは何か　入門編」

基調講演として、増田さんがドメイン駆動設計とは何かについて話されました。

ソフトウェア開発の難しさ

  • 複雑さに設計で立ち向かう。
  • 2年後、3年後にシステムがどう使われているかを見据えることは難しく不確定。
  • その確実さの無いものに、どうアプローチしていくか考えることが大事。

ソフトウェア設計の考え方とやり方

  • 複雑なのはドメインそのもの。納期あり、コストありの中でも拘る。
  • モデルと実装を一致させることは相反するので、相当難しい。
    だが、そこに拘ることでソースの分かりやすさ、変更をする時のポイントの捉えやすさが全然変わってくる。
  • 決まってしまった設計を変えようとするのは大変だが、危険だからやらないに振ってしまうとドメインが育っていかない。
    そのため、インクリメンタルな設計とする必要がある。
  • 会話とラフスケッチの中で、うまく言語化できたものを実装にしていく。

ドメインに焦点を合わせる

  • 知識を獲得し、整理、コードで表現する。
  • インクリメンタルに設計していく際に常にうまくいくとは限らない。
    同じインプットでも表現が異なったり、もっといいものがあるんじゃ、もっと工夫できるのではと常に考える。
  • 人間は、言葉でやり取りする。言葉は重要なツール。
  • 会話とラフスケッチで言葉を捉えているか確認。
    ドメインの言葉をきちんと話せていないエンジニアは怖い。自信がないより、そこが分かってすらいない人が一番怖い。

スタイル

  • アップフロントで決まったことを変えないというのはやめるべき。
    あの日に決めたから変えないはやめる。たった一行の変数名かもしれないが変える。
  • 綺麗な資料は整理できた気になってしまう。

※ ここの話は、僕も陥りがちだったなぁと非常に思うところでした。
SIer の頃の癖が抜けないというか、前に決まったのでコレで行きましょうとか、既にテスト済のところなので変数名の変更はやめておきましょうとか。ついついドメインをインクリメンタルに成長させるということよりも目の前の納期や品質の方にばかりウェイトを置いてしまうというか。
また、資料もついつい綺麗なものを作りたくなっちゃいますｗ
コレはもう性分なので、ある程度抜くということを常に意識しながら取組む日々です。

モデルと実装を一致させる

  • モデルと実装を行ったり来たりする。
  • モデルで要点、軸を捉えて、コードでカタチを作る。
  • モデルを踏まえてコードレビューすると要点を捉えてレビューが出来る
  • ユーザー定義型。
    人が作った型を利用するのはみんな得意になったが、自分でもっと目的に特化したものを作り上げるべき。

※ モデルと実装の行ったり来たり、というのは、抽象と具体の行ったり来たりということになりますが、これは物事を考える時に非常に大事だなと僕も最近特に思っていることです。ついつい目の前の具象にとらわれがちになるので、行ったり来たりで、ちゃんと俯瞰した目線でも見ないといけないなと。モデリングをする時に特にそう思います。

モデルと実装の一致を難しくさせる問題

  • オブジェクトの永続化とか仕組みに引っ張られる。
  • それぞれ、ケースバイケースで考えるべき。

※ 画面やテーブルアクセス、ファイルフォーマットとか仕組みや既存のモノに引っ張られがちで色々とモデルがおかしくなるなというのが、最近の僕の悩みだったりするので、この難しくさせる問題は本当に難しいですｗ

ブレークスルーが起こるとき

  • ドメインモデルの軸となる【要点】がみつかった
  • 区分の構造のリファクタリングの中で
  • テーブルアクセス、画面表示を分離できたとき

境界付けられたコンテキスト　異なるコンテキスト間のマッピング

  • 悩んでいる背景、文脈が違うことを意識する。
    生々しい文脈（エンジニアにとってはプログラミングや設計）。
  • 濃い文脈間でどう捉えているかを把握する。

質問

Ｑ．

インクリメンタルな設計をする際に、テストコードについてどの様に扱っているか？

Ａ．

ソフトウェアの言語タイプによると考えている。動的型付け言語であれば必要と思われるが、使用している静的型付け言語だと書かないことが多い。（言語が保証してくれている側面が大きいから）

 

Ｑ．

実際、会話という面だと日本語で会話しているので、プログラミング言語とのギャップが生まれないか？
それを、どう埋めるのか？

Ａ．

ある部分については、日本語でやっている。
基本は、英語に変換しているが、要点を深堀しきれなかった(表現できなかった)時に使っている。ただ、フレームワーク的な制限等もあるので使える所は使ってみているという状況。

 

Ｑ．

現場のシステム担当と話す際に、担当者が分かるレベルで変更の履歴が知りたいといった様なドキュメントが必要とされる様な局面では、どの様にされているか？

Ａ．

コードから分かりやすいドキュメントを出力するようなツールを作るなど実験中。Git の変更履歴をビジュアライズ化するなど。

 

といった感じで、増田さんの基調講演が終わりました。
基調講演ゲストとして伺ったというのもありますが、質問も活発で、DDD Alliance としても伺った甲斐があったなといった展開となりました。

 

続いて、LT 枠。

Easy Array

というタイトルの @yterajima さんの LT だったんですが、「怒られるので書かないでｗ」とのことなので、ヒミツですｗ

こういう発表がたまにあるのも、勉強会会場へ行った人だけの特典だと思います。

DDDから得たもの

というタイトルで、主催の @kanayannet さんの発表。

元酒屋さんでプログラミングは独学という @kanayannet さん。

  • 10年近く前に酒屋から転身 3 年目の頃、DDD 本は分からんかった
  • 原因としては、単純に経験不足、ドメインに囚われすぎていた

10年経って

  • 名前空間の理解
  • 可読性の大切さを知った　一月経っても読めるコードを

  • 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 を読んだ
    設計の大切さをどう学んだらと困っている中、入りやすかった

  • ドメインモデルというキーワードがそもそも分かりにくい
    何のためにから入ると分かりやすかった
  • 共有してわかりやすくしていく
  • 実装に集中してしまったら、たまに振り返ってみる
    つまづいた時に振り返ってみる、隣の席の人に相談してみる
    そうすると気づくことがある
  • ユビキタス言語
    同じ意味の複数の言葉が乱立することを防ぐ
  • DDD が考えるキッカケを与えてくれた

仕様とは

  • 仕様は課題と設計を繋ぐものです　by 酒匂 寛さん
  • シンプルとイージーの違い　by 和田 卓人さん
    シンプルは一つのもの、イージーは人の数だけ存在する
  • 何か通じるものがあると感じた

まとめ

  • 10年ごしに理解が追いついた

 ※ 10年ごしに理解が追いついたとのことですが、色々な知識があってはじめて見えてくる世界があるということを改めて感じた LT でした。最初は点でしか分からなかったものが、線となり、面となり、立方体になるといった感じで、日々の学びがその先に繋がっている。設計は、多角的に色々と知らないといけないので、こういった学び方になるのかなと思います。

ドメイン駆動設計を始めるために必要なチームのつくり方

というタイトルで、@TsukasaGr さんの発表。

世の中には、いろいろな現場の悩みがあるという @TsukasaGr さん。

良いチームとは？

その１　いいたいことが言える
  • オブジェクト指向もアジャイルも正解がない
    なので、言える環境が大事
  • 言いたい時に言いたい事が言える場所を作る
    分報：Slack で言いたいことを言える場を作った
    なんでもOKな何やっているかとかを連携する場
  • 問題の早期解決などに繋がる
その２　だれかのせいにしない
  • チーム全員で動く
  • だれかのせいにしない仕組み
  • KPT＋G
    GKPT でGoodを可視化　なんでもOK
  • みんなで決めるので誰かのせいにしない
その３　情報を楽しめる
  • 情報を楽しめる文化を作る
  • 情報共有 ＋ コミュニケーション
  • パブリックだとハードルが高いのでクローズドな場として Slack でチャネル
  • その日のニュースネタをキッカケに議論
まとめ

※ 良いチームをつくることで、DDD を始める場を作るといった手段と目的が分かりやすいまとめの図だったので、スライドの中を見て頂くといいかと思います。

ドメイン駆動設計するための脱！受身エンジニア心得

というタイトルで、僕も LT してきました。

ドメイン駆動設計に自分が取り組んでいる中で感じた過去の自分との違いや、意識しないと中々ドメイン駆動設計にならないなと思っていることをまとめようと思いました。

伝えたかったこと

今回の LT の中で伝えたかったことは、

ドメイン駆動設計は、「一品もの」を意識して設計すべし

ということでした。

そのための表現として、「工芸的」や「男の料理」といった表現を使ってみたのですが、振り返ってツイートを見てみると反応してくれていたので伝わったのではないかな〜と思います。

 脱！受身エンジニア

そんな「一品もの」を作るということに対して反しているものは何かと考えた時に出てきたのが、「よくある SIer 構造」でした。自分も、その構造の中で働いてた時もあったので色々と自分自身にも染み付いてしまってます。*2

ただ、振り返ってみると悪いのは構造そのものではなく*3、その中で漫然と受身になってしまっているエンジニアなのではないかなと思い、今回の「脱！受身エンジニア」というタイトルとなりました。

受身のエンジニアとなると、ちょっと極端に言うとコードモンキーといった感じで、何も考えず、ただ漫然とコードを書くといった感じのエンジニアになってしまいます。
やはり、頭を使わないとドメインを捉えることもできませんし、それをモデルとして表現したり、コードに落としたり、そもそも顧客の価値は何なのかといったことも分かっていない状態になります。

これでは、ドメイン駆動設計をやれる状態ではない*4ので、受身エンジニアを脱しないといけません。

工業品と工芸品

SIer でよくやるピラミッド型の下請けモデルでの開発やウォーターフォールでの開発といったやり方は、いかに部品を分解して機械的に同じように生産するかといった構造になりがちです。パッケージ開発なども、ほとんど同じものを横展開して、大量生産しようといった考え方から来ているやり方だと思います。工業品を作る時のやり方ですね。

一方、ドメイン駆動設計での開発に取り組んでいて思うのが、そのドメインの知識を獲得して、モデルやコードを作っては、また新たな気付きで作り直してといった手間暇をかけたやり方をしていかないと、ドメインを理解したり実装したりすることはできません。
一品一品丁寧に、同じ点や違う点を見極めて作り上げていくといったやり方だと思います。工芸品を作る時のやり方ですね。 

この違いがあるので、今まで工業品を作ってきた時と同じようにやろうとしても、うまくいくはずがありません。
初期に手間暇がかかるリスクがあったとしても、ゆくゆくのビジネス変化や変更に柔軟に対応できるモノを作ろうとするのかどうかで、ドメイン駆動設計に取組むかどうかといったことを関係者でしっかりと認識合わせする必要があると思います。

まとめ：男の料理

これは、一緒にドメイン駆動設計で開発をしているメンバーと話している時に出てきた言葉なのですが、

ドメイン駆動設計は、男の料理

だねと。

主婦は冷蔵庫の中身で、ササッと料理して提供してくれるパターンが多いと思いますが、男の人が料理する時は、レシピ通りになるように具材を仕入れてきて、若干無駄かもしれないぐらいしっかりと飴色玉葱になるように炒めてみたり、包丁もいいものを使ってといった形から入ったりと、手間暇かけて料理するパターンが多いかと思います。

ドメイン駆動設計での開発というのは、そんな感じで捉えて、じっくりと料理が出てくるのを待つ必要があるのではないかというたとえです。

まあ、男の料理が手間暇かかったからといって、美味しいものが出てくるとは限らない所が恐いところですがｗ
逆に、主婦がササッと作ってくれたけどメッチャ美味しいのもありますしねｗ

Vue.jsによるSPAのDDDについて考える(導入編)

というタイトルで、@t_pori418 さんの発表。 

  • ドメイン駆動設計の説明は、割愛ｗ
  • 実装でどういうアプローチしているかについて
フロントエンドの DDD

まとめ

  • 画面とデータ主体の実装にはならないように
  • ドメインモデルにわけて
  • 増田さん本の 7 章がオススメ

ドメイン駆動設計と関数型プログラミング with TypeScript

というタイトルで、 @childhooooo さんが発表。

元ロケットの組込み関係エンジニアだったという@childhooooo さん。

参照透過性が破壊されるもの
  • 再代入　→　変数を破壊
    const 宣言をして再代入禁止とする
  • 副作用のある関数
    何回か呼ぶと結果が違ってくる
ドメイン駆動でモデルの構成要素
  • 値オブジェクト
    残高をオブジェクト化
  • エンティティ
    関数型で使う時は、新しいオブジェクトを生成して返すと良い
  • サービス
    2つのアカウントを取って書き換えるのではなく、2つのアカウントを主として2つの結果を返す
  • モナドとかも話したかったが・・・時間がないので

最後に

LT まで終了した後、その場で懇談時間があり、基調講演や LT の内容で盛り上がりました。

その後、二次会があったので、増田さんと僕も参加してきました。

といった感じで、皆さんと熱くドメイン駆動設計についてや、集約の捉え方、設計や仕事をする上で心理学といった人を知る学問の重要性、勉強会は懇親会も出ると学べることが増えるよねといった色々と多岐に渡るお話ができて楽しかったです。

 

まとめると、群馬*5に遠征できて、すごく楽しかったです。
Gunma.web のみなさま、お声がけ頂き、ありがとうございました。

 

DDD Alliance にご相談がある方がいらっしゃいましたら、http://www.ddd-alliance.org/ のページや Twitter アカウント等へお気軽にご連絡ください。

*1:協賛として、UMLモデリングツール Enterprise Architectでおなじみのスパークスシステムズ ジャパン株式会社にもご協力頂いています。

*2:よく一緒に仕事している時に増田さんに怒られますｗ

*3:ま、構造もよくない（少なくとも僕は嫌い）ですがｗ

*4:というか、そもそもきちんとした設計をやれる状態じゃないですね

*5:しかも、高崎！