発表：カフェインの摂り過ぎにご注意 - Digital Romanticism
産業革命期以降における生活の根本的な変化を題材に、今のエンジニアの生活に警鐘をならすLinda Rising氏の発表の要約と若干のコメント。 要約 アジリティ：個人レベルの可能性 Agility: Possibilities at a Personal Level コーヒー、紅茶、コーラといったカフェインを含む飲み物は、世界中で飲まれている。 カフェインは石器時代から知られていたが、最近になるまでは重要な役割を果たすことは無かった。 産業革命は1800年頃のイギリスにおいて起こった。そこで重要な役割を果たした要素はたくさんあるが・・・ 時計の精度が向上したのは、カフェインが使われ始めた時期と一緒。 時計とカフェインが近代市民社会の発達に大きな影響を与えている。 "Command and Control" 昔は朝食にビールを飲んでいた。 昔のことわざ ワインには知識が住み、 ビールには自由が
静と動の往還としてのモデリング - Digital Romanticism
DCIを参照しつつ「業務分析」について考える はじめに 最近「アジャイル」という言葉をなるべく使わないようにしています。なぜなら、この言葉に込められた「桃源郷へのあこがれ」が、色々なものを見えなくしてしまうような気がするから*1。例を挙げましょう。アジャイルの基本は、「タイムボクシングによるインクリメンタルかつイテレーティブな開発」であると言え、それを実現するために流派によって様々なテクニックが提示されます。Scrumを見てみましょう。Scrumを実現するために絶対的に必要なのは、プロダクトオーナーによって適切に優先順位付けされたプロダクトバックログなわけですが、網羅性と整合性を保証したかたちでバックログアイテムを優先度順に並べるって、実はものすごく難しいことを言っていませんか？ 確かにタイムボクシングによる軌道修正がある程度できるとは言え、「優先順位の低いところは粒度が粗くてもいいよ」で
モックによるインターフェイスの発見 - 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
ドメイン駆動式ソフトウェアの育て方 - Digital Romanticism
レッツゴーデベロッパー2011での発表原稿とスライド 導入 2011年05月28日「レッツゴーデベロッパー2011@仙台」が開催されました。このイベントのテーマは「共有と交流」。"「共有」には、最新技術、知識、復興への想い、それぞれの決意を共有することを、「交流」には、東北と東北圏外のデベロッパーやコミュニティ同士の交流を深めることを込めて。" このイベントにてDDDセッションに登壇させて頂きましたので、そのときの発表原稿とスライドを公開致します。なお、当日はワークとして参加者の方にペアモデリングを行って頂きましたが、このドラフトではその部分を割愛しています。 スライドはこちら また映像はこちらで公開して頂いています。 さて今年4/9にDDD日本語版が出版されました。それから２ヶ月弱、翔泳社様から、はやくも増刷のお知らせを頂きました。多くの方々とおかげと深く感謝しています。さて、この増刷が
関数型Scala（２）：関数 - Mario Gleichmann - Digital Romanticism
この記事はMario Gleichmann氏による、「Functional Scala」シリーズの第２回「Functional Scala: Functions | brain driven development」を、氏の許可を得て翻訳したものです。（原文公開日：2010年10月31日） 関数型Scalaの第２話へようこそ！前回は、コアとなる考え方を調査し、式に基づく関数の適用を、関数型プログラミングの基本的な処理方式として抽出しました。今回は、Erik Meijer博士（※1）であれば、関数型プログラミングの必需品（the bread and butter）と呼ぶであろうものから始めましょう。それは・・・なんと・・・関数です（BGMとしてトランペットが鳴り響いていると想像して下さい） 関数を呼び出すためには（これは、関数を引数に適用すると表現されます）、まず、関数を定義しなければなりま
DCIアーキテクチャの理論とGrailsによる実装 - Digital Romanticism
第12回G*ワークショップにて行った講演のスライドと発表原稿 はじめに 11/9にJGGUG様主催にて第12回G*ワークショップが開催されました。そこで、「Model On Grails - DCIアーキテクチャへの道すじ-」と題しまして、DCIアーキテクチャについて講演させて頂きましたので、その際のスライドと発表原稿を公開します。 スライドはこちら アジェンダは以下の通りです。 導入 先駆者たちが遺したもの オブジェクト指向の死角 DCIアーキテクチャ サンプル 導入 今回のテーマは「DCIアーキテクチャ」です。日本では、2010年の1月にJames O. Coplien氏が来日して講演したことで知られるようになりました。Googleグループのメーリングリストを見る限りは未だ黎明期にありますが、何か大きく化けそうな気配を漂わせていると言えるのではないでしょうか。 このDCIアーキテクチャ
ドメイン駆動設計入門 - Digital Romanticism
"Beautiful Develpment"（10/27 DevLOVE）の講演資料と原稿 はじめに 本日（10/27）、DevLOVE様主催で、"Beautiful Develoment"と題されたイベントが開催されました。これは「ドメイン駆動設計（"DDD:Domain-Driven Design"）」を題材に、入門から実践までを語り尽くすというコンセプトのものです。このイベントにおける講演のトップバッターとして、ドメイン駆動設計の根底にある基本的な考え方についてお話しさせて頂きましたので、講演資料と原稿を公開いたします*1。 スライドはこちら アジェンダは以下の通りです。 導入 オブジェクトとは？ モデルとは？ ドメイン駆動設計とは？ まずは、ドメイン駆動設計のベースとなっている、「オブジェクト指向」や「モデル」について整理した上で、実際にドメイン駆動設計とはどういうものかを見ていき
組織パターン トップ10 - James Coplien - Digital Romanticism
この記事はJames Coplien氏の記事「Organizational Patterns: Building on the Agile Pattern Foundations」を、氏の許可を得て翻訳したものです（元の記事が長いため抄訳としています）。（原文最終更新日：2006年7月9日） 目的の統一性（"Unity of Purpose"） 顧客の参画 ("Engage Customers") ドメイン専門家という役割 （"Domain Expertise in Roles"） アーキテクトがプロダクトをコントロールする （"Architect controls Product"） 作業の均等な分配（"Distribute Work Evenly"） 関数の所有者とコンポーネントの所有者 （"Function Owner and Component Owner"） 雇われアナリスト （
ドメイン特化言語とモデル駆動エンジニアリング - Johan den Haan - Digital Romanticism
この記事はJohan den Haan氏の記事「DSL and MDE, necessary assets for Model-Driven approaches - by Johan Den Haan」を、氏の許可を得て翻訳したものです。（原文公開日：2008年8月11日） 私はこれまで、モデル駆動エンジニアリング（MDE）について、多くの記事を書いてきました。MDEはモデル駆動アーキテクチャ（MDA）よりも広い概念で、モデリングのさまざまな切り口とソフトウェアエンジニアリングプロセスの考え方を付け加えるものです。MDAが注力するのは技術的な可変性です。これは、プラットフォームから独立したモデルとそうでないモデルとを区別し、こうしたモデル間での相互変換を定義することで達成されます。一方、MDEが注力するのは、アプリケーションドメインの可変性です。これは、主題領域（"subject are
アーキテクチャを支える言語 - Digital Romanticism
FowlerDSL本のAlternative Computational Modelを足がかりとして、ソフトウェアアーキテクチャにおけるDSLの役割について考察する。 導入 Martin Fowler氏はWeb版DSL本の中で、「DSLにおいて重要なのは、言語それ自体ではなく、DSLによって構築される意味モデル（"Semantic Model"）である」ということを繰り返し述べています（意味モデルについては、以前こちらのエントリで紹介しました）。その上で、この意味モデルが持ちうる、ある性質について「もう一つの処理モデル（"Alternative Computational Models"）」と題された章で説明されています。 ここで「もう一つの」（"alternative"）とされているのは、命令的な（"imperative"）処理に対する宣言的な（"declarative"）処理です。こう
モデル・ビュー・コントローラ - Trygve Reenskaug - Digital Romanticism
この記事はTrygve Reenskaug氏の記事「MODELS - VIEWS - CONTROLLERS」を、氏の許可を得て翻訳したものです。（原文公開日：1979年12月10日） モデル モデルは知識の表象です。モデルは１つのオブジェクトであるかもしれませし（あまり面白くはありませんが）、複数のオブジェクトからなる構造かもしれません。 モデルとその一部には一対一の対応関係がある一方で、モデルとその所有者によって知覚された世界の表象との間にも一対一の対応関係があります。したがって、モデルの各ノードはその問題における識別可能な一部分を表象しているのです。 モデルの各ノードは、同一水準の問題を扱うものでなければなりません。問題指向の各ノード（例えば、カレンダーの予定）を実装の詳細（例えば、パラグラフ）と一緒にすることは混乱を招きますし、良くない形式と考えられます。 ビュー ビューはモデルの
レイヤとデータからみるDCIアーキテクチャの実装 - Digital Romanticism
DCIアーキテクチャに従ってCRUDアプリケーションを実装する際のポイントを整理する。 導入 Trygve Reenskaug氏によって提唱され、主にJames O. Coplien氏によって理論的な確立と普及が進められているDCIアーキテクチャですが、まだ実装事例はそれほど多くありません。このブログではこれまで「割り勘」を題材にDCIアーキテクチャに基づくCRUDアプリケーションを実装しつつ、アプリケーションの全体像について考察してきました。今回は割り勘アプリケーションをふりかえりつつ、もう少し実装の詳細について考えていきます。 アプリケーションレイヤ アプリケーションレイヤとはDDDにおいて説明されているレイヤの１つで、ドメインレイヤを薄くラップし、タスクに応じて適切なドメインロジックの呼び出しを行うという責務を与えられています。 アクションクラス 具体例として、割り勘アプリケーション
Greg Young流CQRS - Mark Nijhof - Digital Romanticism
この記事はMark Nijhof氏のブログ記事「CQRS à la Greg Young」を氏の許可を得て翻訳したものです。（原文公開日：2009/11/11） この記事は以前のブログである"blog.fohjin.com"にて公開していたものです。 以前、2日間の講習を受けた時に、ビールを飲みながらGreg Young氏とドメイン駆動設計について語るという幸運に恵まれたことがあります。その時の話題は専ら、コマンドクエリ責務分離（CQRS:Command and Query Responsibility Segregation）パターンに関するものでした。Gregは、Eric Evans氏が著作において説明したドメイン駆動設計を受け継ぎ、主に技術的な実装を進化させています。コマンドクエリ分離（CQS）は元々Bertrand Meyer氏によって考案されたもので、オブジェクトのレベルで適用さ
Digital Romanticism
2024/3/5にオライリー・ジャパン様より出版された拙訳『組織を変える5つの対話 ―対話を通じてアジャイルな組織文化を創る』からすぐに使える具体的なテクニックの紹介 組織を変える5つの対話 ―対話を通じてアジャイルな組織文化を創る 作者:Douglas Squirrel,Jeffrey Fredrickオーム社Amazon 導入 解説Iと解説IIでは本書の背景にある思想について扱ってきました。今回は予告通り具体的なテクニックについて解説していきたいと思います。 本書において組織変革のゴールとして目指しているのは、いわば「適切な権限委譲と現場での柔軟な意思決定による機動的な組織運営」と言えるでしょう。これは、次に挙げる5つの対話を通じて組織文化を整えていくことで実現できるとされています。 信頼を築く対話 不安を乗り越える対話 WHYを作り上げる対話 コミットメントを行う対話 説明責任を果た
ScalaによるDCIアーキテクチャ：ローンシンジケート再考 - Digital Romanticism
GroovyによるDCIアーキテクチャのサンプル実装で明らかになった２つの問題点をScalaによって解決する。 導入 前回のエントリでは、DCIアーキテクチャの構想に従った実装を示しつつ、言語的な制約から来る問題点を２つ提示しました。以下に再掲します。 ミックスインしたロールクラスにキャストすることができないため、ロールクラスを使用する際に型の安全性が確保されていない。追記：asTypeを使用することで、ミックスインしたクラスへのキャストが可能です。uehaj様より指摘を頂きました。（2010/06/04） ロールクラスが定められたふるまいを実行するためにはデータ構造についての知識が必要だが、それを静的に保証することができていない。 これらはいずれも型の安全性に関する問題で、アーキテクチャの問題というよりは言語仕様の問題です。そこで今回はScalaを使用し、これらの問題をトレイトと抽象メン
DCIアーキテクチャの実装：ローンシンジケート - Digital Romanticism
DCIアーキテクチャの概要を整理した上で、DDDに登場するローンシンジケートを用いたサンプル実装を示す。 DCIアーキテクチャの概要 Trygve Reenskaug氏とJames O. Coplien氏によるDCIアーキテクチャの構想は、「DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien」にて解説されています。ここでは、オブジェクト指向の本質が人間のメンタルモデルを捉えることにあるとした上で、オブジェクト指向の問題点とその解決方法が語られます。オブジェクト指向の問題とされているのは、構造を捉えることに長けている反面、ふるまいをとらえることが苦手であるという点です。具体的には、特定のふるまいをどのクラスにおくべきか悩んだり、エンティティクラスが大量のメソッドで肥大化してしまうといったことが挙げられるでしょう。 この問題に対する解決は、オブ
モデル駆動エンジニアリングのために汎用言語とDSLを組み合わせる - Johan den Haan - Digital Romanticism
この記事はJohan den Haan氏のブログ記事「http://www.theenterprisearchitect.eu/archive/2008/04/15/combining_general_purpose_lang」を、氏の許可を得て翻訳したものです。（原文公開日：2008年4月15日） モデル駆動エンジニアリングに関する以前の記事で、私はMDEの基本的な原則は「全てがモデルである」ということだと述べた。モデルとその要素にはファーストクラスの地位が与えられている。本質的な違いは、モデルがもはやプログラマのための単なるドキュメントとして使用されるだけではなく、ソフトウェア開発を駆動させるために直接利用できるということだ。モデルは、実装、変換、ソフトウェア成果物の諸相、システムに関する視点などを定義するのに用いられる。この記事で、私はモデルとは何なのか（モデルに関する様々な利用シナ
DSL開発：ドメイン駆動設計に基づくドメイン固有言語開発のための７つの提言 - Johan den Haan - Digital Romanticism - digitalsoulのブログ
この記事はJohan den Haan氏のブログ記事「DSL development: 7 recommendations for Domain Specific Language design based on Domain-Driven Design」を氏の許可を得て翻訳したものです。（原文公開日：2009年5月6日） ドメイン固有言語（DSL）という用語は今日多く聞かれる。DSLとは与えられたドメインの要求に対処するために開発される言語である。ドメインは問題領域（例えば、保険、健康管理、運送）である場合もあれば、システム的な側面（例えば、データ、プレゼンテーション、ビジネスロジック、ワークフロー）である場合もある。これは制限された概念を用いて言語を作るという考え方であり、これらの概念は特定のドメインに焦点を絞ったものである。この考え方により、開発者の生産性とドメインエキスパートとのコ
モデルが息づく場所 - Digital Romanticism
"Domain-Driven Design"におけるドメインモデルの性質について簡単にふりかえった上で、そのドメインモデルが位置づけられる領域について整理する。 導入：ドメインモデルとは DDDにおける主要な主張は、ソフトウェアが対象とする領域（ドメイン）についてのモデリングを正確に行った上で、それをソースコードにおいて表現するというものでした。ドメインモデルとはつまり「ドメインについてのモデル」なのですが、これは実体としてアプリオリに存在するものではなく、「現実を解釈することによって、目の前の問題を解決する上で重要となる側面を抽象化したもの」（p.2）、あるいは「ドメインエキスパートの知識が厳格に組織され、選択的に抽象化されたもの」（p.3）とされてます。つまり、現実世界を写し取ったものではなく、ある特定の視点に基づいて世界を切り取ったものである、ということですね。もちろん、ここで言われ
DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism
この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。本文内の図の著作権はArtima, Inc.に帰属します。（原文公開日：2009年3月20日） 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
