2015年03月29日makopi23のブログmakopi23が日々の生活で感じたことを気ままに綴るブログです。3月定例会「アジャイル時代のモデリング」に参加してきました。参加者は50人くらいでしょうか。この日の登壇者は平鍋さんで、内容も私が興味ある「モデリング」ということで、期待大でした。ちなみにこのイベントに対して平鍋さんがブログに書いてます。要求開発アライアンスにて、「アジャイル時代のモデリング」お話しました。20当日から1周間以上経ってしまいましたが自分用復習メモ。モデルを使うのか?人間はイメージの方が概要を上手くつかむことができる。モデリングの本質コードと重なるモデルを全部書くのは意味がない。保守が大変になるだけ。そこで、モデルを2つに分ける。KeepsとTemps。全体像をみんなに示して、すすめていくのが、Keeps。軽く保ってコードと一緒にメンテしてください。その場限りのモデルが、Temps。この2つを区別してスプリントの活動で使ってはどうか。ユースケース■アーキテクチャアーキテクチャは、全体の構造を示す見取り図。私はココを担当してます、と指を指せることが重要。クラス図、パッケージ図が代表例。システム全体の構造的な表現。ポイントは、「よく知られたパターンが存在する」という点。アジャイルの人は「アーキテクチャは発現する」というが、それは怖いと思っているw過去にやったことある例を必ず僕(平鍋さん)は見るようにしている。アーキテクチャは、システムの要求からはこない。過去の人類の知見からも来るし、会社の老人の知見からも来る。アーキテクチャのカタログやパターンから持ってくる。「これを使う」と決めたからといって、詳細化するとビッグデザインになってしまう。フレームワークもアーキテクチャの選択の1つ。Architectureこの本にいろんなパターンが出てくる。ノー知識で乗り込むより、知見を勉強してからのほうがずっと良い。Astahこのパケッジ図はずっとメンテしている。各パッケージに役割を書いておくのがポイント。依存関係を書くのも超大事。■ドメインモデルこのシステムが扱うデータの構造を表す。最終的にはクラスの名前になったり、DBの名前になったりする。DDDを読んでください。ソフトウェア開発の実践)(2011/04/09)エリック・エヴァンス商品詳細を見る問題領域(ドメイン)の概念とそれらの繋がりがドメインモデル。できれば、用語間の関係があったほうがいい。名前は、英語と日本語の両方つけたほうがいい。英語の方はプログラミングに落ちる。人間のコミュニケーションレベル全ステークホルダーで使う語彙。プログラミング・レベルコードを構成する要素の名前付けで出てくる。普段見る名前は、概念モデルの言葉だけが出てくるようになるC言語でmalloc関数の呼び出しとかがロジックの途中に出てくるが、それはシステムの言葉。業務のドメインの中に、急にシステムの言葉が出てくるのはおかしい。10回ループを回したいだけなのに、呪文みたいな構文で意味がない。Rubyは、10.timesでいいじゃん、としている。その方がちゃんと意味を表している。UseCase「キー」がポイント。キーユースケースについては、発動してからシステムをどう通って実現されるかのメカニズムを書く。ユーザから見たシステムの代表的な使い方を書く。アーキテクチャを貫くメカニズムを書く。開発者には教育的な例示となる。Kepps上にTempsを重ねるホワイトボードにKeepsを投影して、その上にTempsを書く。Tempsはカジュアルモデリング。Scaling100人のアジャイルチーム、どうしますか。Lessというのがある。本の中の引用で、ケントベックが「ソフトウェアは分割統治できない。