Entries

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
この記事にトラックバックする(FC2ブログユーザー)
http://exphenomenologist.blog100.fc2.com/tb.php/534-81f954e8

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する

エリック・エヴァンス『エリック・エヴァンスのドメイン駆動設計』

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
(2011/04/09)
エリック・エヴァンス

商品詳細を見る

Domain Driven Design(DDD)についての名著。ポイントになるのは、ユーザと開発者が同じ言語を用いて、それをモデル分析や設計、実装に渡って全般的に使用すること(ユビキタス言語の使用)という観点。業務領域(ドメイン)で使われる言語によって分析・設計・実装を行うことにより、当のシステムを開発する視点がブレなくて済むし、開発の各段階でのミスコミュニケーションも減る。システムは業務上の問題を解決するために構築されるものであるから、その設計はドメインに対するモデルを作ることに主眼を置く。ドメインモデルはつまり、業務領域における概念分析になる。本書ではそれはクラス図を用いて行われるが、それはユースケース図でも、UMLを用いない形でも可能だろう。ユーザが理解できさえすればコードそのものでも構わない。ただし、DOAは明らかにこれになじまない。

本自体は大きいが、DDDの実際のポイントは最初の3章ほど。後はいかにドメインに注目して分析を進めていくかのデザインパターン集になっている。UI、アプリケーション、ドメイン、インフラという基本的な4つのレイヤー構造、エンティティ・値オブジェクト・サービスといった構成要素、ドメインにおける重要な制約や条件を分離するための仕様やストラテジーといったところが面白かった。また複数のドメイン間の関係や大規模なものになったときにそれぞれを分離するための戦略的パターンも、おぼろげながら実際に取られているものだろう。

これを実際のプロジェクトで使うのは(日本では?)たしかにけっこう困難だ。まずもってユーザへの負荷が大きい。DDDのポイントやいくつかのデザインパターンについては理解してもらわなければならないし、反復的開発においてドメインモデルの深化を行うには長期に渡って時間を割いてもらわなければならないだろう。エンジニア側が複数チームだった時、ユーザ相互に認識の相違があった時、どう調整すればいいのか。プロジェクトとしての進捗管理はどうするのか。見積もりは?成果物は?とはいえ、既存の開発手法にも取り入れられるところは多いので使えるところはありそうだ。
スポンサーサイト
この記事にトラックバックする(FC2ブログユーザー)
http://exphenomenologist.blog100.fc2.com/tb.php/534-81f954e8

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。