どしろうと製作所：WebLog

■紹介範囲

今回の紹介範囲は、興味が強かった4章、5章、7章、8章、9章の5つになります。
※DBはあまり詳しくありませんでしたので、6章は外しています。

以降は4章から順番にお絵かき紹介をしてみます。

なお、著者の増田さんいわく「現場で最初にやるのは序盤の内容の徹底だ」とのことでした。現場でできていない場合には、最初の1～3章が非常に重要な内容となります。これらの必要とされる各技術、方法に対しても「なぜ必要か？」という記述がされておりますので、とても理解しやすいです。


■4章：ドメインモデルの考え方で設計する

早速ですがお絵かき紹介。　※各章はお絵かきから紹介します。


4章ではドメインモデルについての説明と、どのように設計を進めるかという説明が行われております。特に興味があった部分は「ドメインモデルと他のモデルとの関連性」の部分でしたので、その理解について図にまとめてみました。
「コト」を中心として整理しながら業務知識を整理してドメインモデルという部品倉庫に整理する。その部品を使いながらロジック配置や名前を整理していくという流れがあります。

また、全体を俯瞰しながら要点や重要な関係を共通理解にするために、コンテキスト図、業務フロー図、パッケージ図、主要クラス図が役立ちます。この関連性を図には明示しています。
これらの情報も、業務の知識を得て理解を深めにつれて変化させていくことになります。

この「全体の俯瞰」に関しては、著者の増田さんがこちらのSlideShare（クリックでリンク）にて「書くべきだったもの」で紹介されておりますが、神崎さんが提案した「RDRA（「らどら」と読む）」の概念が多く取り入れられております。

※RDRAの参考
・書籍：モデルベース要件定義テクニック
・さくさく要件定義（RDRAの紹介スライド）

RDRAは各モデルの概念の関連性を整理することで、つながりのある要件定義を行うことができるよい手法です。あわせて学習すると非常におもしろく、理解もより深まりますね。


■5章：アプリケーション機能を組み立てる



三層モデル（プレゼンテーション層/アプリケーション層/データソース層）におけるアプリケーション層（サービス）で、ドメインモデルをどのように使用するかという説明がされております。
業務知識となるロジックはドメイン層に配置し、アプリケーション層はドメイン層の部品を使用します。

サービスクラスは登録と参照で分けることを意識して、複合した使い方は「シナリオクラス」で組合せて使用するという感じですね。


■7章：画面とドメインオブジェクトの設計を連動させる



画面に関しては、まず問題となりやすい部分の図だけ整理してみました。
単純な場合には画面とロジックが対応しやすいですが、画面が増えると「同一ロジックが複数個所に散らばる」、「業務ロジックと表示ロジックが混ざる」という問題が発生して、複雑化しやすくなります。



理想的にはどこまでも画面とドメインモデルが一致すること…として、小さな画面に分けた「タスクベース」を紹介しておりました。
この際、画面とドメインモデルが一致していない時は「おかしい」と考えて、分析してみるということです。なぜなら、画面は顧客の関心ごとがあらわれますし、ドメインモデルも関心ごとで整理しているため、これらが一致してない場合には何らかの「ズレ」があるということが見えることになります。そのため、再検討が推奨となる…ということです。

あと、画面に関してちょっとだけ「どうしようかな」と思った部分がありましたのでそれもお絵かきしてます。


エラー（例外）に対しての分担方法ですが、人による入力の想定外（異常）対策、在庫がゼロである場合の例外などに分かれると思います。
この際、入力の想定外は入り口でガードしたいです。例えば「同時購入可能なチケット販売の最大枚数」などは業務ロジックに入りそうですが、画面でガードをかけたい部分です。

この辺は画面でロジックを持たせたくなりそうですので、どのようにするかは実装をやりながら考えてみたい部分でした。


■8章：アプリケーション間の連携

8章は「他と比べて浮いている」という意見もありますが、（通信系のシステムに絡んだことがある）自分的にはとても楽しい内容でした。





提供側は「何でもできる大きなハコ」で通信（One Size Fit All）をせずに小さい単位で登録・参照を可能にしよう。業務ロジックを扱う利用側でそれを組合せて使用できるようにしよう…という方針ですね。
この考え方を基本方針にすることで、スッキリ考えることができそうです。
※既存の通信を踏襲することが多いので、実際には悩ましい部分もありますが…


■9章：オブジェクト指向の開発プロセス



プロセスモデル（WFを代表とする逐次型モデル、アジャイルを代表とするインクリメンタルモデル）の違いによって、成果物や体制がどのように変わるかという紹介がされています。
ドキュメントが簡易なものとなり、質疑情報やラフスケッチ（ホワイトボードを写真で取ったもの）に変わるという状況が、理由も含めて説明されておりました。

成果を出すためにどのようなプロセスモデルを使用するか、成果物をどのような形式にするか…を判断するための参考になりますね。


■おしまい

以上、特に興味の強かった章に関して、理解ついでにお絵かきでまとめてみました。

わかりやすく内容も詰まっていますが、持ち運びやすい軽さで非常によい書籍です。著者からのサインも頂きましたので最後に紹介しておわります^^