1. ドメインオブジェクトを作ることは部品化・再利用になっている
2. ロジックの 置き場所
2.1. オブジェクト指向には ロジックを置く場所がない
2.2. ロジックはどこに置くべきか?
2.2.1. オブジェクトの外側
2.2.2. オブジェクトの内側
2.3. ダイコン時代の設計手法 - ロジックをどこに置くのか - ひがやすをblog
2.3.1. ビジネスロジック
2.3.1.1. エンティティ (≒Value Object) とは切り離す
2.3.1.2. ユースケース固有のものは サービス層に置く
3. ソースの構成
3.1. 定数
3.2. イベント
3.2.1. 何かのタイミングで呼び出されるもの
3.2.1.1. マウスクリック
3.2.1.2. 画像ロード完了
3.3. コマンド
3.3.1. 状態を変化させる
3.3.2. 値を返さない
3.3.3. トップレベルコマンド
3.3.3.1. イベントから呼び出される
3.3.4. 下位レベルコマンド
3.3.4.1. トップレベルコマンドから呼び出される
3.4. クエリー
3.4.1. 値を返す
3.4.1.1. 検査値
3.4.1.2. 新規作成値
4. アーキテクチャ
4.1. コマンドクエリ責務分離 (CQRS: Command and Query Responsibility Segregation)
4.1.1. Greg Young流CQRS - Mark Nijhof - Digital Romanticism
4.1.2. システムの 更新処理と 参照処理を 分離する
4.1.3. Event Sourcing
4.1.3.1. イベントを 蓄積する
4.1.3.2. 最新の 情報は イベントから 求める
4.1.3.3. 関数型で 処理できる
4.2. DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism
4.2.1. アルゴリズムを記述できる場
4.2.1.1. オブジェクトに分散された
4.2.1.1.1. 1967 年
4.2.1.1.2. ソフトウェア工学によって
4.2.1.2. アルゴリズムを取り戻す
4.2.2. ユーザーの頭の中にあるものを反映
4.2.2.1. データー
4.2.2.1.1. 世の中に対するユーザーのメンタルモデルを表象する
4.2.2.1.2. 「何であるか」を表す
4.2.2.1.3. 責務を持たない
4.2.2.2. ロール
4.2.2.2.1. ユーザーの頭の中にあるアクション
4.2.2.2.2. 「何をするか」を表す
4.2.2.2.3. 特定状況での振る舞い (メソッド) を持つ
4.2.2.2.4. 責務を持つ
4.2.3. コンテキスト
4.2.3.1. データーとロールの紐付けテーブル
4.2.4. インタラクション
4.2.4.1. ロールの観点から エンドユーザのアルゴリズムを記述するもの
4.2.4.1.1. ロールを使ってアルゴリズムを実行する
4.2.4.2. ユースケースシナリオに含まれる
4.2.5. 例
4.2.5.1. 振替
4.2.5.1.1. データー
4.2.5.1.2. ロール
4.2.5.1.3. コンテキスト
4.2.5.1.4. インタラクション
4.3. MVC および 派生物
4.3.1. MVC
4.3.1.1. モデル
4.3.1.1.1. ドメインの すべてを 表す
4.3.1.1.2. 変更を ビューに 通知する
4.3.1.2. やはり お前らの MVC は 間違って いる (スライド)
4.3.1.3. ビュー
4.3.1.3.1. モデルに アクセスして データを 取り出す
4.3.2. MVAC
4.3.2.1. MVC + Application
4.3.2.1.1. MVC を さらに 抽象的化した 方式
4.3.2.2. はてなで 考案
4.3.2.2.1. 株式会社 はてなの 開発戦略 （スライド)
4.3.2.2.2. Web Application を 綺麗に 設計する ための MVAC という 考え方
4.3.2.3. 内部WebAPIの呼び出しコスト - MVCモデルの”次”
4.3.3. MVP
4.3.3.1. C# と 諸々 MVP (Model View Presenter) パターン
4.3.3.2. Model View Presenter
4.3.3.2.1. Wikipedia
4.3.3.3. MVC との 違い
4.3.3.3.1. MVP では View が ユーザーからの 入力イベントを 受け取る
4.3.3.4. Presenter
4.3.3.4.1. Model や View に 属さない ものに 関する 処理を する
4.3.4. PAC
4.3.4.1. Presentation, Abstraction, Control
4.3.4.1.1. Wikipedia
4.3.4.2. PAC (Presentation Abstract Controller): 浜村拓夫の 世界
4.3.4.2.1. 他の リソースへの リンクが まとまっている
4.3.4.3. Delphi の フォームに 部品を 貼る イメージ
4.3.4.3.1. それぞれの 部品が 状態 (データー) を 持っている
4.3.4.4. MVP との 違い
4.3.4.4.1. 階層構造を 作れる
4.3.5. MOVE
4.3.5.1. [翻訳] MVCは 死んだ。 MOVEする ときが きた
4.3.5.2. Model
4.3.5.2.1. アプリケーションが 知っている ことを 全て カプセル化する
4.3.5.3. Operation
4.3.5.3.1. アプリケーションが 行う ことを すべて カプセル化する
4.3.5.4. View
4.3.5.4.1. ユーザーと インタラクションする
4.3.5.5. Event
4.3.5.5.1. 上記 すべてを 結びつける
4.3.6. 単に どこで 切るかの 違いの ような 気が する
4.3.6.1. 切り分けが 属人的に なる
5. 独自に 思い付いた 方法
5.1. 設計方法
5.1.1. ユースケース作成
5.1.2. ロバストネス図作成
5.1.3. コントローラを 関数と みなす
5.1.4. 関数の 第 1 引数を レシーバ, それ以外の 引数を メンバー変数または 引数とする
5.1.5. 関数の 内部は 呼び出す サブ関数を 並べる
5.1.5.1. トップダウンで 書く
5.1.5.2. ○○とは ○して ○して … したものである, のように 書く
5.1.5.2.1. Haskell の 知見
6. クラウド時代の ソフトウェア構成法
6.1. BASE
6.1.1. Basically Available
6.1.2. Soft-state
6.1.2.1. ネットワーク用語では
6.1.2.1.1. 状態が リフレッシュされないと タイムアウトする
6.1.2.1.2. リフレッシュされると 再び 状態を 持つ
6.1.2.1.3. FAQ: What does “Soft-State” mean?
6.1.2.2. 単に 「状態の 厳密性は 追求しない」 という こと かも?
6.1.2.2.1. 触ってみよう！ビッグデータを支えるクラウド技術 - NoSQLの世界へようこそ：ITpro
6.1.3. Eventually consist
6.1.3.1. 結果整合性
6.1.3.1.1. 長い 時間の 後には 整合性が 取れる
6.1.4. クラウドでの 新しい ACID, そして BASE トランザクションと CAP 定理 - Fight the Future
6.1.5. ACID に 代わる トランザクション 方式
6.1.5.1. クラウド時代の トランザクション - きしだのはてな