BPStudy #141 DDD実践の現場レポート

「BPStudy #141 DDD実践の現場」に参加したので、
そのレポートです。

 

www.slideshare.net

ドメイン駆動設計でなぜつくるのか

「進化を続けるソフトウェアを手に入れるため」
「ソフトウェアの変更を楽で安全にするため」

 

進化を続けていくのか、
それとも地獄に苦しんでいるのか

 

最初から「 The 現場」な感じがした。
プログラムに手を加えるときに「手を加えよう」と感じれるか
問われている気がした。
まさにソフトウェア開発の天国と地獄の分岐点。

 

ドメイン駆動設計の本質とは、
「ソフトウェアの核心にある複雑さに立ち向かう」こと

 

核心にある複雑さとは?
 → ビジネス活動自体の複雑さ
  → ビジネスの複雑さをSWで扱う
    →ビジネスが持っている複雑さが複雑さの核心となる

 

 この話を聞いていて、

漠然と「車のドライバーと自動運転の関係に似ているな」と感じた

ドライバーがビジネスルールで、自動運転するためにソフトウェアを作っている。
ドライバーはいろいろなことを判断しながら自動車を運転する。
つまり複雑なビジネスルールをこなしている。

こう考えるとしっくり来た。

 

ドメインロジック
=SWで実現したビジネスルール

 

核心を上手く扱えると

  • 周辺の複雑さが軽減される
  • 核心と周辺の依存関係が明確になる
  • 全体の構造の改善に波及する

ビジネスルールに注目して設計することで、
自然とプログラム全体がシンプルになっていく様子をイメージしつつ聞いていた。

ドメイン層を独立させる(ビジネスロジックを抽出する)

ビジネスの活動を継続的に学び続けること
=進化を続けるSWを手に入れるためのポイント
 -> コアドメインに集中する
   ビジネスを深く洞察する

 いつもプログラムを設計するとき、
実装する機能をユーザーの操作(画面)を起点に考えてしまっていた。
トップダウン的なアプローチ)
それに対して、ビジネスロジックを起点にすることで、
ビジネスルールの中盤(ロジカルな部分)からブレイクダウンするイメージだろうか?

そして、「学ぶ」「ドメインモデル抽出」「コーディング」
この流れを継続的に繰り返す。

ドメイン駆動をする上の6つの問

1. 継続的にビジネス活動を学んでいるか
2. コアドメインに集中しているか
3. ビジネスを深く洞察しているか
4. ドメイン層を独立させているか
5. モデルと実装は密に結合しているか
6. システム間の秩序の改善をつづけているか

 

広く均一に秩序を作ろうとするのではなく
ピンポイントで取り組むと急に秩序ができる 

毎日続けていれば大きな成果につながる

 

「広く均一的に取り組む」<「ピンポイントで取り組む」

 

 この関係を聞いたとき、

「これなら取り組める」と素直に思えた。
複雑なコードを見かけると、プログラム全体がひどい状態だと感じてしまい、
全体を何とかしないとと思ってしまい憂鬱になるが、
少しずつならできそうだと感じた。

しかも「ピンポイントで取り組むだけで急に秩序が出る」という話は、
いままで意識したことはなかったが、感じたことがあった。

カイゼン」に対する重苦しいイメージが少し晴れた気がした。

 

DDDでいうモデリングは、
コードをきれいに書くためにどう整理したら良いか

 

ドメインロジックを独立させる
-> 関心事からメモリ上でどう扱いどう処理するかを考える
  (画面やデータソースを意識しないようにする)

ロジック(ビジネスルール)の構造を解明する

 

仮説モデルを作り実装する
うまくいったら仮説モデルを作り込む
(モデルとドメインを言ったり来たりして作りこんでいく)
(実験を繰り返しながら作りこむ)

 

コアドメインに集中する

 =複雑さの核心に集中する
  (軸となるロジックと枝葉となるロジックを切り分ける)

 

実験しながら軸の関係の着地点を探っていく
 (迷ったら複数実験的に仮実装してみてもよい)

 

大きなロジックになるとコードから離れてしまいがちだが、
コードで実験できるところまで習得すべき
(小さなロジックと同じ)

 

ここが「駆動」の由来なのだなと実感した。

ロジック的な試行錯誤。
ロジックの探求。

職場がウォーターフォールでの開発が主体だからか、

フロントローディング」
「設計を済ませてから実装」
「設計が完了するまで実装をしてはならない」
「設計は頭を使ってナンボ」
「動かしながら開発するのはNG」ということをよく言われてきた。

でも、本当に求めるのは、ソフトウェアに価値を与え続けることであり、
そのための

「進化を続けるソフトウェアを手に入れる」
「ソフトウェアの変更を楽で安全にする」

 なのだから、完全に手段が目的になっていると感じた。

 

プログラミングは、もっと創造的であるべきだと再確認できた。

やっぱり駆動(モデリング、コーディング、テスティング)しながら開発がしたい。

 

職場のプロセスの中にどう織り交ぜていけば良いか。。。。