アーキテクチャについて知ってみる 「ゆらぎのある決定」以降のまとめ #DevKan #devlove
- kamatamadai
- 3356
- 0
- 1
- 2
#DevKan ドメインに関してやるべきこと。 ・スコープ策定 ・アクター抽出 ・ドメインの境界策定 ・モデリング
2014-12-20 15:43:20#DevKan 和智さんのドメインの定義は、システムが対象とする業務領域。システムがプログラミング対象に限るなら、ITサービス運営モデルよりも狭い
2014-12-20 15:43:23では、その決め方は?やるべきことは、 1. スコープを決める 2. かかわる人々 = アクターを決める 3. ドメインの境界を定める 4. ドメインの中身をモデリング となる #DevKan
2014-12-20 15:43:52#DevKan いわゆる機能との違い 機能一覧の目的は、見積もり、インデックス作り。画面/帳票/バッチ ドメインの方は関係性が重要。 境界/関係
2014-12-20 15:45:04ドメイン分析で作るのは単なる機能一覧ではない。機能一覧はどちらかと言うと見積もり用のIndex。ドメイン分析ででてくるのは、モデル間・ドメイン間の関係性を分析し、それがシステム境界と一致しているのかを考える必要がある #DevKan
2014-12-20 15:46:02DDDは(今のところ)人を幸せにしてない。それはDDDが「何をすべきか」をあんまり明らかにしてないからではないか #DevKan
2014-12-20 15:47:47DDD難民の定義は、昔「英語+防弾仕様で読めなかった。でも翻訳で救われた」、今「DDD"で"やっても成功しない」。 #DevKan
2014-12-20 15:48:30#DevKan DDDのポイント ・ユーザのドメイン知識およびメンタルモデルに従うモデリングが重要 ・ユーザから学び、ユーザーにフィードバックする ・実装形式にこだわりすぎない方がよさそう ・レイヤリングは常に重要
2014-12-20 15:48:31機能一覧はシステムの外面を捉えているけど、ドメインはシステムが扱う「物」とその関連を捉えているイメージを受けている ドメインでは確かに見積もりや進捗管理とかは難しいかも
2014-12-20 15:49:08DDDのポイントは、ユーザと一緒にドメイン分析する、ということ。そこから、そのモデルそのまんま実装しようとすると躓くことが多いのでは。 #DevKan
2014-12-20 15:49:22Eric 自身が DDD Whirlpool の ver 1.0 のリリースに失敗してるしなw domainlanguage.com/ddd/whirlpool/ #DevKan
2014-12-20 15:52:39機能とドメイン境界の種別は「ユースケース実践入門」の「雲・凧」の絵が分かりやすい。機能の一階層上の「凧レベル」がドメイン #DevKan
2014-12-20 15:53:45#DevKan 発芽:業務上重要な概念がある程度の粒度に成長する
2014-12-20 15:54:16例えば、DDD本の貨物予約システムの場合。オーバーブッキングという概念は、最初はコード中の簡単な条件分岐になってしまうが、それが業務上重要な概念とわかれば、ドメインとして浮上してくる。 #DevKan
2014-12-20 15:57:32