参加してきました。今回は発表はなしでした。
### TableDataGateway (わたなべさん) 読書会の議論でも発言させていただきましたが、TableDataGatewayは（非常に荒いレベルの）オブジェクトの設計方針について、わかりやすい指針を示しているものに過ぎないと考えます。
* 具体的な対象と照らし合わせた上での、責務の範囲 : 具体的には・・・RDBの構成要素（テーブル、カラム、複数テーブルなど）を相手にするGateway一般の中で、TableDataGatewayは、テーブル（もしくはテーブル類似のビューなど）を相手にする。責務の範囲をテーブルとする * クライアントから見た場合のインスタンス関係。もっと言えば、アイデンティティ。：具体的には・・・TableDataGatewayは1テーブルにつき1個。（テーブルの数は簡単に数えられる（苦笑）ので、インスタンスのアイデンティティも容易に理解できる）
### RowDataGateway (和田さん) あとで書きます。
### ActiveRecord(inoueさん) Railsのデモが中心。やっぱRailsすげー！
ちょっと気になったのは、Railsの実行モデル。あれだけ評価・処理実行・自動生成が走るとなると、CGIでは・・・きついよね。多分。
### 議論を聞いて。 ビジネスロジックの割り当て、データアクセスの議論が混在している印象。 ここは分けて話さないとまずいっす。
せっかくファウラーたんが、整理してくれているのだから。（わかりにくいけど）
### 角谷さんの意見に同意 わからない部分を曖昧に、抽象的に触れて流すよりも、わからない部分を明確に提示し、自分が理解できている（と思っている）部分を具体的に示すほうが良いと思う。ここはそれが許される「場」であると思います。
言い方を変えれば、せっかくなんだから燃料を投下しましょうよ。 どんなに炎上しても誰かが整理してくれるし。となるかも。
### 資料（半）公開希望。 再度資料を見て、記憶を呼び戻したいので。 懇親会で酔っ払ったので、良く思い出せないというは秘密。
### 戦果 ogijun氏が蔵書の一部を販売していたので、以下の2冊を購入。
* ユースケース実践ガイド 1500yen : 最近、プロセス屋さんの世界で next ユースケースが熱いらしいので、あらためて基礎を抑えておこうかと。 * ソフトウェアエンジニアリング基礎知識体系 600yen : なんか、書き物書くときに便利そうじゃない？たとえば・・・「IEEE xxx では、?における特性として、a) ・・・性、b) ・・・性、c) ・・・性、が求められている。本ドキュメントでは、a) ・・・性の・・・について記述する。」とか。
[…]