モックによるインターフェイスの発見 - Digital Romanticism
設計ツールとしてのモックの使い方について考える。 導入 先日、"Mock Roles, not Objects"の日本語版「ロールをモックせよ」を公開しました。この論文は2004年に書かれたもので、著者はSteve Freeman氏、Nat Pryce氏、Tim Mackinnon氏、Joe Walnes氏という豪華メンバーです。また、Steve Freeman氏とNat Pryce氏は『Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))』（いわゆるGOOS）の著者でもあり、"Mock Roles, not Object"で語られている思想はGOOSのベースになっているとも言えます。 今回は、この"Mock Roles, not Objects"（以下、MRnO
読書マップとDDD 〜DDDは３冊目の本？〜 - Digital Romanticism
技術書の読み方を考えつつ、『ドメイン駆動設計』を位置づける。 はじめに 〜１冊目の本〜 あなたは技術書をどのくらい読んでいるでしょうか？多い人は月何冊も読んでいるでしょうし、もう何年も読んでいないという人もいるでしょう*1。あるいは、「買っているけど読んでいない」ということもあるかもしれませんね。私にも積んでしまっている本があります。 技術書はすでにかなりの数が出版されており、その数は増え続けています。経験を積んだ方であれば、「自分にとって必要な本を見抜く眼」を持っているものですが、これから学ぼうとする方にとっては、読んだ方がよさそうな本の数も値段も絶望的かもしれません。このエントリの目的の１つに、『ドメイン駆動設計』の紹介があることは否定しませんが、それ以上に、「技術書の読み方」について考えてみたいと思います。 仕事としてプログラミングに携わる人であれば、「退職するまでに１冊も読まない人
モデル・ビュー・コントローラ - Trygve Reenskaug - Digital Romanticism
この記事はTrygve Reenskaug氏の記事「MODELS - VIEWS - CONTROLLERS」を、氏の許可を得て翻訳したものです。（原文公開日：1979年12月10日） モデル モデルは知識の表象です。モデルは１つのオブジェクトであるかもしれませし（あまり面白くはありませんが）、複数のオブジェクトからなる構造かもしれません。 モデルとその一部には一対一の対応関係がある一方で、モデルとその所有者によって知覚された世界の表象との間にも一対一の対応関係があります。したがって、モデルの各ノードはその問題における識別可能な一部分を表象しているのです。 モデルの各ノードは、同一水準の問題を扱うものでなければなりません。問題指向の各ノード（例えば、カレンダーの予定）を実装の詳細（例えば、パラグラフ）と一緒にすることは混乱を招きますし、良くない形式と考えられます。 ビュー ビューはモデルの
モラルと技術−パート２ - Digital Romanticism
プロジェクトにおけるモラルと技術について考える、２部構成の第２部。第１部はこちら。第２部ではスクラムが抱えている問題点と、プロジェクトを技術的に下支えする共通基盤チームについて考察する。（この記事は、今年３月にパート１のみ公開していたものを整理したものです。） スクラムの問題点 もうだいぶ前のことになりますが、James Shore氏のブログ記事「James Shore: The Decline and Fall of Agile」に端を発した、スクラムについて再考する動きがありました。M. Fowlerがブリキに「FlaccidScrum」を載せていたことは記憶されている方も多いのではないかと思います。さて、「モラルと技術」と題した２部構成記事の前回では、スクラムのプロダクト・オーナーのモラルについて「Agile Software Development.com」の記事を題材に考えてきま
BDDと共通言語 - Greg Young - Digital Romanticism
この記事は、Greg Young氏のブログ記事"BDD and the Shared Language"を、氏の許可を得て翻訳したものです。（原文公開日：2007年10月16日） ここ数ヶ月というもの、私はすました顔でここに座り、BDDには自分にとって理解すべきようなものは何もない、と言ってきました（そして同じような意見の人とも会ってきました）。BDDは単にTDD+DDDであり、このコンセプトになじみがない開発者に教えるのが簡単なように組み替えられただけだというのです（Aaron Feng氏の優れた説明や、Raymond Lewallen氏によるより詳細な議論によればですが）。 しかしそこには多くの違いがあり、私から見ればDDDとBDDは同じものがほとんど何もなく、比較してはいけないものです。その違いは開発チームや全体としてのプロジェクトに関するものではなく、これから見ていくように、むしろ
ブログ：アジャイル開発スタック - Digital Romanticism
Dan Bergh Johnsonn氏による、スクラム、BDD、DDDの関係を解説したブログ記事について、要約とコメント。 要約 スクラム・BDD・DDD - アジャイル開発スタック Dear Junior - Letters to a Junior Programmer: Scrum on BDD on DDD - an Agile Development Stack アジャイルのプラクティスがどのような関係にあるのかについて、長いこと考えてきた。日常使っている３つのプラクティスについては、特にそうである。それが、ドメイン駆動デザイン（"Domain-Driven Design"）、ふるまい駆動開発（"Behaviour-Driven Development"）、スクラム（"Scrum"）の３つである。これらについては、スタック（"stack"）としてとらえるのが適切だと考えるに至ってい
BDDとDDD - Dan North - Digital Romanticism
この記事はDan North氏が、QCon London 2009において行った発表"BDD and DDD"のスライドを、氏の許可を得て翻訳したものです。 ドメイン駆動デザインとは何か？ 「ドメインにフォーカスを当て、そのドメインがソフトウェアに大きな影響を与えるようにしむけること。」-Jimmy Nilsson (ADDDP) 「コア・ドメイン」を識別する 「コア・ドメイン」とは、ステークホルダが最も重要だと考えるもの 輸送会社は品物を移動させる。この会社のコア・ドメインは何だろうか？ 手配 経路指定 品物がどこにあるかを把握すること コア・ドメインは最も有益な会話がどの部分にあるのかを教えてくれる ・・・つまり、知識の咀嚼（"knowledge crunching"）を行う上で、最も豊かな縫い目（"seams"）が何かということを教えてくれる 共通理解を発展させる ドメインをステーク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
