昨日の話を、結局まとめると、システムは、
ユーザーと（ＵＩで）接するサービス層と
データを管理するデータ(モデル）層があって、
これをどこかでつないでるという形になる。
そのまま素直に考えると、ＭＶＣになるし、Domain-Driven Design（ＤＤＤ）でも、ドメインがデータモデル部分、サービスがサービス層ということになってくるかもしれない。
いずれにしろ、サービスとデータモデルに分割して考えられる。
そして、サービスは(業務）機能ベース、ユースケースベースで提供されるのに対し、データモデル部分は、ドメインの概念モデル(クラス）として提供される。
ここで、開発方法論を考えると、
（１）サービス＝機能＝＞ユースケースベースで考えていくもの
（２）データモデルも含めて考えるもの
の２種類に大別できると思う。（１）は、目的→業務機能とプロセスを分析していくが、そのプロセスの実現可能性をトレースするために、データで確認したりはしない。
（２）は、プロセスを入出力で定義し、その入出力をもとにしてつくるデータモデルを明確にしていくという手法になる。
（１）の手法は
目的→要求 i*
要求 ユースケース法
であり、この場合、データ構造が確定していないので、アジャイルに持っていったほうがやりやすい。
コンポーネント化する場合は、KobrAのほうが向いている
（２）の手法は
目的→要求 KAOS
要求 ICONIX
であり、この場合、データ構造が確定しているので、さらに
データ→ＤＢ 正規化（ＥＲ図）
画面遷移
フレームワーク決定・・・
と詳細化(プログラミング化）していける。
コンポーネント化する場合は、UML Compornentのほうが向いている
（１）は、目的といっても、問題から入り、データモデルによる裏取りをしないので、作りやすいメリットがある（会社の不平不満はあげられる人が多いが、じゃあ、どうしたらいいの？それ実現できるの？というと、答えられなくなる人も多い）。
そのため、日本においては（１）の流儀のほうが、進展している。
（２）は、達成すべきゴールの状態から落とし込んでいくので、一貫性があるが、その分作りにくいかもしれない・・・
そんなところかな
アクセス
トータル
ランキング
