【ドメイン駆動開発】のための上流工程【再】入門＜第48回IT勉強宴会in東京＞ : ATNDに参加してきた
講師はDOA界隈の有名人である渡辺幸三氏。
業務システムの構成要素
業務システムは原則的に一点もの
実装技術に依存するのは危険
- 実装は割りと誰でもできる領域
- オブジェクト指向プログラミングが楽しいという人は危ない
- 特定のプログラミング言語の枠組みに20代30代の時間を捧げてはいけない
- いずれ若い人に取って変わられるし、単価も上がらない→家族を養えない
- プログラミングは5年やれば充分だぞ、上流の仕事にシフトしよう
- (MEMO)上流工程（分析）と実装を直結するのがドメイン駆動設計だと思うんだけどなぁ...
業務システムの重要な要素
- データモデル: 無いとお話にならないが難しい
- 簿記（の知識）: 業務システムに関わるSEで簿記3級相当の知識がないとヤバイ（顧客と会話できない）
- ただし、3級レベルでOK（2級は不要）
- UIのパターン: 入出力のUI、要件に応じた最適なUIは大体決まってる、引き出しを持つことが大事
業務システムの専門家について
- ひとつのシステムだけをよく知っているSEは、業務システムの専門家ではない
- システムを超えたところにある普遍的な知識を知る人が業務システムの専門家
間違ったデータモデル設計
- 最初にUIを作る→そこからデータモデルを作る
- UI主導のデータ設計はかつてのPOA（プロセス中心アプローチ）と一緒であり、不適切なデータ設計になる可能性が高い
- しかし、未だにUIをベースにDB設計するSEは多いよね（嘆息）
ではどうする？
- 客と会話しながらデータモデルを作っていく
- (MEMO)この辺りはドメイン駆動設計と同じくモデル駆動開発ぽい
オブジェクト指向プログラミング言語について
- けちをつけるわけではないが...
- 業務システムを作るのにオブジェクト指向言語はあまりに汎用的過ぎである
- Javaで業務システムを作るのはクレイジーなのではないか
- 汎用的であるために、何でもできるので保守性が低下するのでは？
- だからデスマーチがなくならないのではないか
- 汎用機時代の言語は驚くほど機能が少なかったが、それで充分だったし、機能が少ないゆえに実装が混乱することもなかった
- (MEMO)要するにDSL主義者だった
シナリオライターとデータモデラー
- 下手なシナリオライターのシナリオは読みにくい/上手なシナリオライターのシナリオは読みやすい
- 下手なデータモデラーのモデルは読みにくい/上手なデータモデラーのモデルは読みやすい
設計が上手くなるために必要なこと
- 自分の設計にケチを付けてくれる人を探す
- 設計は作業の成果を隠しやすいので批判されないように操作できる
- 自分の設計を公開して、積極的に批判を受けよう
質疑応答
- ER図は一枚にまとめるべきか否か
- →サブシステム単位で使用するテーブルだけ載ってればOK（全てのテーブル構造は理解しておく必要はある）
- →開発時に全てのテーブルを参照しなければいけないのであれば、設計がおかしい可能性が高い
- モデリングの失敗をどう見つけるか
- →他人にレビューしてもらうしかない
- →他人に説明していると自分で気づけたりする
(2016/02/23)