Pinto公開に向けて #16 ― 責務駆動設計で仕切り直すことに決めた - 岩本隆史の日記帳（アーカイブ）
あらすじ Pintoというソーシャルブックマークサービスを、Rubyで開発中です（GitHubリポジトリ）。開発中に気づいたことや工夫した点などを、備忘録も兼ねて書いています。その16回目です。 ActiveSupportのDependenciesを使って、やめた autoloadを山ほど書くのが面倒なのでactivesupportのDependenciesを使ってみたのですが、ライブラリの読み込みに時間がかかり、Webサーバ起動時やユニットテスト時にイライラさせられたので、採用を見合わせました。 軽いautoloaderを自分で書けば解決できる問題なので、そのうち書くかもしれません。Zend_Loaderが恋しいとかなんとか。 ラップを外した 前回、String等をラップしたわけですが、なんでもかんでもラップしてしまったため、クラス数がふくれあがり、収拾がつかなくなってしまいました。なの
ドメイン駆動設計という仕事の流儀
8. ドメインモデル指向の設計パターン 業務活動のトリガー 業務手順の要約 業務の知識 ドメイン 起動 ドメイン 委譲 ドメイン イベント サービス モデル 入会申込 受付() -申込番号 { 会員とは？ -氏名 検証(); 入会とは？ -連絡先 記録(); 申込とは？ -申込日時 通知(); 受付とは？ } "something interesting "represents a Use Case scenario" “an Object Model which affects the domain" "delegate to other objects " of the Domain” [EAA-dev, Fowler] [GRASP : Controller] [PoEAA] 9. ドメイン層の基本部品 業務イベント 入会申込 会員リポジトリ 会員登録サービス << interfac
オブジェクト指向の原則集 - 徳田新之助のプログラム備忘録
近況：米国に1週間予定の出張にいったら5週間に伸びてしまいました。 久しぶりに、ブログを更新しようと思います。 今回は、オブジェクト指向の原則集です。 取り上げる原則は以下の通りです。 GRASPパターン（９つ、デザインパターンや他の原則より先に取り上げたい原則(s)です。） クラスの原則（５つ、頭文字をとってSOLIDの原則とも言います。） パッケージの原則（６つ。３つがパッケージ内、３つがパッケージ間のものです。） その他の原則、パターン、用語など（DRY、KISS、YAGNI、BCE図、code smellなど） 簡単な説明、個人的な解釈（丸括弧で記述します）と、関連した記事のリンク等も貼っておきます。 GRASPパターン GRASPは、General Responsibility Assignment Software Patterns の略です。Pは、Principleとする場合
GRASPパターン - Strategic Choice
GRASPについてGeneral（汎用）Responsibility（責任）Assignment（割り当て）Software（ソフトウェア）Patterns（パターン）オブジェクト指向設計の基本とは、適切なクラスに適切な責任を割り当てることであるここでいう責任とは、クラスが何らかの処理を実行する責任（実行責任）と、クラスが持つ情報を把握する責任（情報把握責任）のことである。そして、この責任割り当ての指針がGRASPである。責任駆動開発設計responsibility-driven design : RDD「責任」「役割」「強調」の観点から設計を行う。GRASPはRDD一部であり、その手段である。一覧責任を割り当てる際の指針 生成者情報エキスパートコントローラ保守性・拡張性・再利用性を高めるための指針 疎結合性高凝集性クラスを洗練する時に使用 多相性人工品間接化バリエーション防護壁参考実践U
Railsで導入してよかったデザインパターンと各クラスの役割について - masato_hiのブログ
3年ほどRailsを書いてきてある程度知見が溜まってきたので、忘れないためのメモとしてKPTと導入例を交えながらダラダラと書いています。 見出しの命名規則は クラス名/ディレクトリ名の単数形をupper camel caseにしたもの + KPT です。 Keepは今後も使うもの、Problemは開発規模によっては問題が発生する(した)もの、Tryは現在使用していないが使用したほうが良いと思っているものです。 これらすべてを導入すれば上手くいくというわけでもないので、開発規模に合わせて適切に採用していくと良いと思います。 DDDやデザインパターン等見聞きはしているものの詳しいわけではないので間違っている部分等あるとは思うのでその辺りはコメントでご指摘お願いします。 はてブコメント欄で頂いた指摘内容等についてはまとめの後でまとめて返答を記載しています。 Asset (Keep) app/as
ActiveRecord のモデルを整理する7つのパターン - tkawachi Blog
7 Patterns to Refactor Fat ActiveRecord Models という記事があり、読もう読もうと思いつつ1年くらい経ってしまった。 ようやく読んだので理解した内容を書いておく。 コード例は元記事のもの。 Rails で thin controller, fat model を心がけていると、model がマジで激太りしてヤバくなる。 実際に自分が仕事で書いている rails アプリも激太りしててヤバい。 この blog の筆者が作っている CodeClimate で C 判定をもらう程度には肥満体型になっている。 Mixinに抜き出さない! Model が太ってきた時に考えるのは ActiveSupport::Concern を使って感心事を抜き出して、Mixin にすることだと思う。 実際に手元のアプリでも models/concerns/ なんていうディレ
エンタープライズアプリケーションアーキテクチャパターン・基本パターン編 - Strategic Choice
書籍「エンタープライズアプリケーションアーキテクチャパターン」の各パターンで、基盤として使用されている、基本的なパターンをまとめます。第18章 ベースパターン一覧「ベースパターン」（Base Patterns） ゲートウェイ（Gateway）マッパー（Mapper）レイヤースーパータイプ（Layer Supertype）セパレートインタフェース（Separated Interface）レジストリ（Registry）バリューオブジェクト（Value Object）マネー（Money）スペシャルケース（Special Case）プラグイン（Plugin）サービススタブ（Service Stub）レコードセット（Record Set）関連アーキテクチャ編オブジェクトリレーショナル編オフライン並行性編セッションステート編基本パターン編（本編）出典エンタープライズ アプリケーションアーキテクチャパタ
2.4. アプリケーションのレイヤ化 — TERASOLUNA Global Framework Development Guideline 1.0.0.publicreview documentation
本ガイドラインでは、アプリケーションを、次の3レイヤで分割する。 アプリケーション層 ドメイン層 インフラストラクチャ層 各層には、以下のコンポーネントが含まれる。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
