モデルと実装を結びつける

ドメインモデルを持たないプロジェクトは知識のかみ砕きとコミュニケーションによる恩恵を受けることができない。

モデルを初期段階でのみ作成しモデルとコードとの結びつきを維持していないプロジェクトはモデルがだんだんと的外れになっていき、プロジェクトに悪影響を与えることすら出てくる。

モデル駆動設計では分析モデルと設計と分けずに、両方の目的に使える単一のモデルを作り出す。

モデル駆動設計では 分析としても設計としても利用可能なモデルとするために以下の２つの目的を満たすようにモデルを設計する。

感じたこと

ここはうちのプロセスと少し異なっているように感じています。

ドメインエキスパートを含むチームで概念モデルと呼ばれるモデルをまず作あ成し、それを受けて開発チーム内で分析モデルを作成しています。必要に応じて概念モデルはメンテナンスされるが分析モデルは実装前に作成されて、その後メンテナンスはされません。

チーム内では分析モデルは実装されたコードに現れるため別途作り出すのは無駄が多いという判断が行われました。概念モデルはドメインにとって主要な概念を表現し、文政モデルは実装にとって実用的であることを目指して作られている感じです。

あ、でも大きく外れていないかもしれない。

分析モデルは概念モデルの粒度を細かくしたもので概念モデル上のつながりなどなどは分析モデルでも守られるので。

分析モデルをそれぞれつなぎ合せて粒度を荒くしたら概念モデルが出来上がると思うので、プロジェクトの中でモデルは間違いなく１つと言えるのかもしれない。

ドメインエキスパートからドメイン知識を引き出す上では粒度が細かすぎない概念モデルの方が有利という判断なのかもしれない？

ここら辺はまた勉強していこう。別の現場での事例とかも知りたいかもしれない。

ソフトウェア開発は製造工程がなく全てが設計工程であり、単純な作業はない。

筆者の経験が語られている。過去に磨き上げたモデルがプロジェクトで使われなかったことがあり、その理由を２つ考えている。

モデルの意味が引き継ぎの際に失われたおそらくUML図やらなんやらでモデルを残していたのだろうがコードとして残すことはしなかった。そのため失われたのではないかと考察している。コードを通してが一番詳細が伝わりやすいということでしょう。
モデルが実装からフィードバックを得られなかったモデルのある側面が実装上うまくできていないなどの問題があったときでもモデラへのフィードバックはなかった。そのため開発者は問題を含んでいるモデルを遵守することなく自分たちで実装を進めた。同じような状況になったら同じことが起こりそうな気がします。というより自分がその実装者の立場だったらモデルは無視してしまうだろうなぁと感じる

心に留めておきたいことが書かれていました。 アプリケーションのためにモデルを機能させる方法を理解していない場合、そのモデルはソフトウェアと無関係になる

これ、上に書かれていることと全く同じことを、つい最近した気がします。とりあえず動いたらレビューに持っていけるしそれでいいじゃないか！という考え方でコーディングしていて爆死しました。この言葉はしっかりと心に刻んでおきましょう。。。

プログラマはモデラである必要がある。モデルに貢献する人は誰しも一定の時間をコードに触れることに費やさなくてはならない。コードの変更に責任を負う人は誰でも、コードを通じてモデルを表現することを習得しなければならない。

うん。すいません本当に。気をつけます。

ここまで読みながら、うちの現場では概念モデルを作っているアーキテクトの人はコードに触ってないなーと思って現場との違いを感じていましたが、どうやら第4部の「戦略的設計」のところでそこらへんのトピックを扱っていそうな雰囲気を感じる。気になるので先にそっちを読んでもいいかもしれない。