プログラマの思索

第6回ドメイン駆動設計読書会に行ってきた。
感想をメモ書き。

【参考】
第６回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper

Pages ・ dddosaka/reading_ddd_report Wiki

[ 技術講座 ] Domain-Driven Designのエッセンス 第1回

[ 技術講座 ] Domain-Driven Designのエッセンス 第2回

[ 技術講座 ] Domain-Driven Designのエッセンス 第3回

[ 技術講座 ] Domain-Driven Designのエッセンス -目次-

【1】今回の勉強会は、ちょっと難しいと感じた。
おそらくその理由は、第5回に参加できなかったため、DDDの基本パターン「モデル駆動設計」をきちんと読み込めていなかったからだろうと思う。

DDDの基本パターンは、[ 技術講座 ] Domain-Driven Designのエッセンス 第1回に書かれているように3つある。

１・ユビキタス言語
２・モデル駆動設計
３・実践的モデラー

【2】モデル駆動設計が意味するもの

(引用開始)
● Model-Driven Design（モデル駆動設計）パターン

ユビキタス言語を実現するには、プログラムコードにおいてもドメインモデルが正確に表現されていなければならない。
ドメインモデルとプログラムコードとが常にお互いを反映するように保つことで、ドメインモデルの変更がそのままコードの修正を促し、逆にコーディングの中で得られた新たなドメイン知識が即座にドメインモデルに反映されるようになる。
このようにモデルとコードを緊密に結びつけるのがモデル駆動設計（MDD）である。
MDDを実践するには、開発ツールやオブジェクト指向プログラミング（OOP）のようなプログラミングパラダイムが必要になる。
(引用終了)

モデル駆動設計では、モデルとソースは一致する。
つまり、「コードを変えるとモデルも変わる」。
モデラーと開発者は、ユビキタス言語でモデルの意味を共有する。
だから、プログラマもモデルの意味をユビキタス言語として理解して、プログラミングする必要がある。

ここで、モデル駆動設計が言う「モデルとソースは一致する」主張には2つの実現方法がある。

【２－１】モデルからソースを生成する場合は、モデリングツールによるフォワードエンジニアリング

この方法は、かつてのMDAが目指していたもの。
「WF型開発の上流工程だけ腕を上げれば、プログラミングは設計モデルから自動生成されたソースで置き換えられる」という考え方が好きな人がこだわる。

最近は、BPMやBRMSのように、ワークフローエンジンないしビジネスルールエンジンも自動生成できる製品が出てきたので、この手法が最注目されているように思える。

BPMとワークフロー: プログラマの思索

なぜ超高速開発が話題になるのか～キーワードはビジネスルール管理システム(BRMS): プログラマの思索

【２－２】ソースからモデルを生成する場合は、リバースエンジニアリング

業務システムの開発案件で非常に多いリプレース案件でよく出てくる。
既存の古いシステムを捨てて、新しいシステムへ置き換えるというレガシーマイグレーションで、この設計手法がよく使われる。
普通は、既存の仕様書が保守されていないために使い物にならず、本番稼動中の画面や帳票からER図や機能をリバースエンジニアリングする。
リプレース案件とレガシーマイグレーションについては、過去にたくさん書いてきた。

システムのリプレース案件が最も危険な理由: プログラマの思索

ERPの落とし穴part4～システム移行という名のデスマーチ: プログラマの思索

レガシーマイグレーションという名のシステム移行はデスマーチになりやすい: プログラマの思索

このリバースエンジニアリングでよく使われる設計手法がデータモデリング(DOA)。
データベース定義書がなければ、データ移行もできない。

そして、機能仕様書とER図から、CRUD表も作る時が多い。
CRUD表があれば、リバースした設計書を理解しやすいし、その後のテスト仕様書にも流用できる。

個人的には、データモデリング技法としては、T字形ERが一番有効だと思う。
T字形ERでは、既存の画面や帳票からリバースしてモデリングする技法として確立されているからだ。

【２－３】リバースエンジニアリングによるモデル駆動設計のアンチパターンとして、勉強会の議論で「最新の建材を用いて築かれた竪穴式住居」というアンチパターンが紹介された。

発端は、渡部幸三さん著「業務システムのための上流工程入門」にあるアンチパターン。

リプレース案件で、旧モデルをそのまま新モデルにマッピングしてしまい、あるべきモデルになっていない。
現実の業務の焼き直しに過ぎず、従来の課題が解決されないまま、新システムが作られてしまう。

「最新の建材を用いて築かれた竪穴式住居」というパターン名には、石器時代の竪穴式住居をコンクリートの建材で作り直した時、その建材の特徴や最新の機能を利用せず、例えば、高床式倉庫のまま作ってしまったり、ねずみ返しのように不要な機能までそのまま再現してしまった、という意味が込められている。

レガシーマイグレーションのアンチパターンとして「最新の建材を用いて築かれた竪穴式住居」は覚えておくと良いと思う。

【２－４】但し、モデル駆動設計の実装方法については「ドメイン駆動設計」では何も語られていない。
今後の課題なのだろう。

【3】実践的モデラーが意味するもの

(引用開始)
● Hands-On Modeler（実践的モデラー）パターン

もしモデラーがプログラムを書けなかったり、プログラマがドメインモデルに興味を示さなかったら、MDDの利点であるモデリングとプログラミングの好循環は生まれない。
また、チームのコミュニケーションもそこで停滞してしまう。MDDを通してユビキタス言語を実現するには、モデラーが動くプログラムを書けなければいけないし、同時にプログラマがドメインモデルを理解し、修正できなければならない。
つまり、チームのすべての開発者は、プログラムを書くモデラーでなければならない。
(引用終了)

【３－１】実践的モデラーパターンは、Coplienの組織パターンにある「アーキテクチャ設計者もソフトウエア実装に参加する」に相当すると思う。
アーキテクトもモデルとソースを行き来しないといけない。
アーキテクト(モデラー)もモデルの実現可能性を調べる必要がある。

パターン１５：アーキテクチャ設計者もソフトウエア実装に参加する

(引用開始)
・問題：どのようにしてアーキテクチャ的なビジョンを実装の段階も持つ続けるのか？

・コンテキスト：開発者の組織が、戦略的な技術的方針を必要としている。

・影響する事柄：全体主義的な統制は、多くの開発チームで、厳格さの程度として観察される。正しい情報は、正しい役割を経由して流れなければならない。

・解決策：アーキテクチャ設計者は、開発者にアドバイスしたり情報交換するだけでなく、ソフトウエア実装にも参加すべきである。
(引用終了)

アーキテクトは単にモデルとして設計するだけでなく、ソースとしての実現方法も考慮しなければならない事実を意味している。
ITの技術革新によって、従来の課題であった「実現可能性の制約」の壁はかなり下がってきている。
特に、クラウドの技術によって、システムの実装方法や配置方法は、従来と比べてかなり変わってきている。
そんな面も考慮して、ベターなシステムを作る必要があるのだろう。