ドメイン駆動設計入門 - Digital Romanticism
"Beautiful Develpment"（10/27 DevLOVE）の講演資料と原稿 はじめに 本日（10/27）、DevLOVE様主催で、"Beautiful Develoment"と題されたイベントが開催されました。これは「ドメイン駆動設計（"DDD:Domain-Driven Design"）」を題材に、入門から実践までを語り尽くすというコンセプトのものです。このイベントにおける講演のトップバッターとして、ドメイン駆動設計の根底にある基本的な考え方についてお話しさせて頂きましたので、講演資料と原稿を公開いたします*1。 スライドはこちら アジェンダは以下の通りです。 導入 オブジェクトとは？ モデルとは？ ドメイン駆動設計とは？ まずは、ドメイン駆動設計のベースとなっている、「オブジェクト指向」や「モデル」について整理した上で、実際にドメイン駆動設計とはどういうものかを見ていき
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
Math - 言語はどこまで小さくなれるか - (unlambda|iota|jot) のすすめ : 404 Blog Not Found
2010年09月27日07:00 カテゴリMathLightweight Languages Math - 言語はどこまで小さくなれるか - (unlambda|iota|jot) のすすめ To Mock a Mockingbird Raymond M. Smullyan [邦訳:数学パズル ものまね鳥をまねる] 「言語設計者たちが考えること」の言語設計者たちが考えた、複雑で豊穣な言語に日々触れていると、ときおりその逆も考えずにはいられません。 言語は、どこまで簡潔になりうるのか、と。 Brainf.ck considered too complicated 小さな言語の代表としては、Brainf.ckがあげられます。人前でいいづらいその名はとにかく、設計は実にエレガントなもので、Shibuya Perl Mongersの現代表の竹迫良範氏をして、 最もタメになる「初心者用言語」は Br
メソッド設計で守るべき10個のルール - A Day In The Life
以前メソッド設計の原則に関する記事を書きましたが 質問をすることで答えは変更されない原則 メソッドの引数はオペランドのみにする原則 それ以前にメソッド設計する上で最低限守った方がよいルールをまとめてみました。 プロパティをメソッドの戻り値代わりに使ってはいけない ファンクションメソッドでプロパティの値を変更してはいけない プロパティをリターンしない インスタンス変数やプロパティをメソッドの引数に渡さない 参照渡の引数をリターンしてはいけない 例外処理を GoTo 文の代わりに使ってはいけない 理由なく id 型をメソッドの戻り値にしない 特定メソッドの呼びだしが前提になったメソッドを作ってはいけない パブリックメソッドからパブリックメソッドを呼ばない プライベートメソッドからパブリックメソッドを呼ばない 以下その詳細です。 プロパティをメソッドの戻り値代わりに使ってはいけない メソッドが呼
言語設計者たちが考えること - 書評 - Masterminds of Programming : 404 Blog Not Found
2010年09月21日18:00 カテゴリ書評/画評/品評Lightweight Languages 言語設計者たちが考えること - 書評 - Masterminds of Programming オライリー社の担当編集者赤池様より献本御礼。 言語設計者たちが考えること Mastermind of Programming Federico Biancuzzi / Shane Warden 伊藤真浩 / 頃末和義 / 佐藤嘉一 / 鈴木幸敏 / 村上雅章訳 [原著:Masterminds of Programming] ソフトウェアに関する人文系書籍としては、間違いなく最重要の一冊。今後これなしでソフトウェアに付いて語ることは慎まれるであろう。 このような重要な一冊に査読者としてお手伝いできたことは、光栄としかいいようがない。 本書「言語設計者たちが考えること」、原著"Masterminds
CakePHPを使ったMVC設計のベストプラクティス - Sooey
CakePHPを使ったMVC設計のベストプラクティス 個人的にはCakePHPはあまり好きではないのですが、CakePHP開発メンバーによるMVCデザインの記事 (CakePHP のおいしい食べ方)で紹介されていたBest Practices in MVC Design with CakePHP (php|architect’s C7Y)はMVCフレームワーク利用者にとってとても有用な情報だったので、訳してみました(php|architectの方には翻訳許可を頂いています)。 この記事を読んでドメインモデルに興味を持った方は、エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)やDomain-Driven Design: Tackling Complexity in the Heart of Softwareに手を出してみるのもいいかも。他に、InfoQにユーザー登録すれ
使える GUI デザイン
EmptyPage.jp > Translations > 使える GUI デザイン 使える GUI デザイン: フリー／オープンソース・ソフトウェア開発者のための手引き 2004年11月28日 Benjamin Roe さんの、Usable GUI Design: A Quick Guide for F/OSS Developers の M.Shibata による日本語訳です。プロジェクト杉田玄白正式参加テキスト。 Update: この記事についてたくさんのコメントをいただいたので、FAQを作って、そのうちのいくつかについて回答することにしました（訳注: FAQ も翻訳しました！）。 イントロダクション オープンソース・ソフトウェアの世界は優れたソフトウェアでいっぱいです。ワードプロセッサから Web サービスにいたるまで、コンピュータでしたいと思うようなおおよそすべての作業において、高
モデルからのレスポンスとエラーを考える - id:anatooのブログ
何かモデルを設計するときに、モデルのレスポンスはどうしよう？モデルが失敗した場合どうやって補足しよう？と迷うことがあるので整理するためにもいくつかのやり方を疑似コードで書いておく。 失敗した時はfalseを返す まずは最も素朴なやり方で。 <?php $result = $model->fetchSomething(); if ($result === false) { fail(); } success($result); 欠点 失敗に関する情報が無い 失敗したかどうかとエラー情報も一緒に返す 上記のやり方の欠点を防いだもの。 <?php list($success, $result, $error) = $model->fetchSomething(); if (!$success) { fail($error); } success($result); 欠点 成功した場合、$succ
ソフトウェア品質の12の属性
システム開発において「品質の向上」という標語がしばしば掲げられますが、 「品質の属性」については無頓着なケースが多いのではないでしょうか。 ひとくちに品質といっても多様な属性があります。 顧客と品質の話で揉めたことはありませんか？ 品質には多様な属性があり、単一の軸で良しあしを決められないという側面があります。 そのため、単に「品質」と言ってしまうと認識に齟齬が生じるのです。 Karl E. Wiegers氏が著書 「ソフトウェア要求」 で挙げた、すべてのプロジェクトが検討すべき12の属性は以下のとおりです。 可用性availability 動作可能時間の指標。システム故障までの平均時間MTTF(Mean Time To Failure)を 平均修復時間MTTR(Mean Time To Repair)とMTTFの合計で割った値。稼働率とも呼ばれる。 効率性efficiency 同じ処理性
ERダイアグラムを編集するAmaterasERDでDB設計
AmaterasERDの特徴 AmaterasERDは、ベースとしてAmaterasUMLのコンポーネントを利用しており、AmaterasUMLの姉妹品といえます。AmatarasUMLについては、本連載第14回「軽量なUMLプラグインAmaterasUML」をご覧ください。AmaterasERDは次のような特徴を持ちます。 物理設計と論理設計をサポート 多くのフリーERダイアグラム作成ツールは物理設計しかサポートしていませんが、AmaterasERDは論理設計も行うことができます。 また、論理設計と物理設計がシームレスに行えるようになっているため、論理設計モードで上流工程のモデリングを行えば、下流工程の物理設計をスムーズに行うことができます。 DDLファイルの生成 さらに、物理設計により作成したテーブルからDDL（Data Definition Language、データ定義言語）ファイル
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記