BPStudy #141 DDD実践の現場レポート
「BPStudy #141 DDD実践の現場」に参加したので、
そのレポートです。
ドメイン駆動設計でなぜつくるのか
「進化を続けるソフトウェアを手に入れるため」
「ソフトウェアの変更を楽で安全にするため」
進化を続けていくのか、
それとも地獄に苦しんでいるのか
最初から「 The 現場」な感じがした。
プログラムに手を加えるときに「手を加えよう」と感じれるか
問われている気がした。
まさにソフトウェア開発の天国と地獄の分岐点。
ドメイン駆動設計の本質とは、
「ソフトウェアの核心にある複雑さに立ち向かう」こと
核心にある複雑さとは?
→ ビジネス活動自体の複雑さ
→ ビジネスの複雑さをSWで扱う
→ビジネスが持っている複雑さが複雑さの核心となる
この話を聞いていて、
漠然と「車のドライバーと自動運転の関係に似ているな」と感じた
ドライバーがビジネスルールで、自動運転するためにソフトウェアを作っている。
ドライバーはいろいろなことを判断しながら自動車を運転する。
つまり複雑なビジネスルールをこなしている。
こう考えるとしっくり来た。
ドメインロジック
=SWで実現したビジネスルール
核心を上手く扱えると
- 周辺の複雑さが軽減される
- 核心と周辺の依存関係が明確になる
- 全体の構造の改善に波及する
ビジネスルールに注目して設計することで、
自然とプログラム全体がシンプルになっていく様子をイメージしつつ聞いていた。
ビジネスの活動を継続的に学び続けること
=進化を続けるSWを手に入れるためのポイント
-> コアドメインに集中する
ビジネスを深く洞察する
いつもプログラムを設計するとき、
実装する機能をユーザーの操作(画面)を起点に考えてしまっていた。
(トップダウン的なアプローチ)
それに対して、ビジネスロジックを起点にすることで、
ビジネスルールの中盤(ロジカルな部分)からブレイクダウンするイメージだろうか?
そして、「学ぶ」「ドメインモデル抽出」「コーディング」
この流れを継続的に繰り返す。
ドメイン駆動をする上の6つの問
1. 継続的にビジネス活動を学んでいるか
2. コアドメインに集中しているか
3. ビジネスを深く洞察しているか
4. ドメイン層を独立させているか
5. モデルと実装は密に結合しているか
6. システム間の秩序の改善をつづけているか
広く均一に秩序を作ろうとするのではなく
ピンポイントで取り組むと急に秩序ができる毎日続けていれば大きな成果につながる
「広く均一的に取り組む」<「ピンポイントで取り組む」
この関係を聞いたとき、
「これなら取り組める」と素直に思えた。
複雑なコードを見かけると、プログラム全体がひどい状態だと感じてしまい、
全体を何とかしないとと思ってしまい憂鬱になるが、
少しずつならできそうだと感じた。
しかも「ピンポイントで取り組むだけで急に秩序が出る」という話は、
いままで意識したことはなかったが、感じたことがあった。
「カイゼン」に対する重苦しいイメージが少し晴れた気がした。
DDDでいうモデリングは、
コードをきれいに書くためにどう整理したら良いか
ドメインロジックを独立させる
-> 関心事からメモリ上でどう扱いどう処理するかを考える
(画面やデータソースを意識しないようにする)ロジック(ビジネスルール)の構造を解明する
仮説モデルを作り実装する
うまくいったら仮説モデルを作り込む
(モデルとドメインを言ったり来たりして作りこんでいく)
(実験を繰り返しながら作りこむ)
コアドメインに集中する
=複雑さの核心に集中する
(軸となるロジックと枝葉となるロジックを切り分ける)
実験しながら軸の関係の着地点を探っていく
(迷ったら複数実験的に仮実装してみてもよい)
大きなロジックになるとコードから離れてしまいがちだが、
コードで実験できるところまで習得すべき
(小さなロジックと同じ)
ここが「駆動」の由来なのだなと実感した。
ロジック的な試行錯誤。
ロジックの探求。
職場がウォーターフォールでの開発が主体だからか、
「フロントローディング」
「設計を済ませてから実装」
「設計が完了するまで実装をしてはならない」
「設計は頭を使ってナンボ」
「動かしながら開発するのはNG」ということをよく言われてきた。
でも、本当に求めるのは、ソフトウェアに価値を与え続けることであり、
そのための
「進化を続けるソフトウェアを手に入れる」
「ソフトウェアの変更を楽で安全にする」
なのだから、完全に手段が目的になっていると感じた。
プログラミングは、もっと創造的であるべきだと再確認できた。
やっぱり駆動(モデリング、コーディング、テスティング)しながら開発がしたい。
職場のプロセスの中にどう織り交ぜていけば良いか。。。。