杉本 啓「2つのドメインモデル―DDDの含意」
Kei Sugimoto, “Two Domain Models - An Implication of DDD”, PHP Mentors, (December 20, 2015) ドメイン駆動設計（Domain-Driven Design: DDD）は、オブジェクト指向、デザインパターン、リファクタリングなど、ソフトウェア設計分野における幅広い知的遺産と交差します。それゆえ、ドメイン駆動設計は、ドメイン指向のアプリケーションソフトウェア開発に馴染むような仕方でこれらの知識資産を統合したものと見ることができます。 こうした見方は妥当でかつ生産的でもありますが、DDDの業績に対しては別の見方もあり得ます。それがこの短い論考のテーマです。 この文脈において、DDDは、「ソフトウェア設計」から、私たちが特別な思い入れを込めて「情報設計」と呼ぶものへの静かな出発として考えることができるかもし
「現場で役立つシステム設計の原則」批判 (2) ～ポリモーフィズムは何のために？～
増田亨氏の「現場で役立つシステム設計の原則]」批判の第２編です。 （２）ポリモーフィズムは何のために？オブジェクト指向の要件本書には「変更を楽で安全にするオブジェクト指向の実践技法」というサブタイトルが付与されています。オブジェクト指向が何かという点については、論者によって違いはあるものの、以下の３つが要件とされることには、多くの人が合意するでしょう。 カプセル化インヘリタンス（継承）ポリモーフィズム（多態）前回で明らかになったように、カプセル化は、オブジェクト指向とは独立にモジュール分割の指導原理としてデイビッド・パーナスにより提唱された「情報隠蔽」を敷衍したものです。オブジェクト指向の要件ではありますが、オブジェクト指向固有のアイデアではありません。 インヘリタンスは便利な機能ですが、コンポジションや移譲により代替できるので、オブジェクト指向の本質的な要件とは見做されなくなってきたかと
「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～
増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本
「Lean Architecture / DCI Evening」参加レポート
2017年10月18日、James Coplienさんとその奥様であるGertrud Bjørnvigさんをお招きして、「Lean Architecture / DCI Evening 」というイベントを開催しました。日本ではソフトウェアパターンやアジャイルのリーダーとして知られるJames Coplienさんは、『 マルチパラダイムデザイン 』（1998年）でドメインとドメイン間の関係を中心に据えた設計パラダイムを提唱していました。Coplienさんは2009年、MVCアーキテクチャの考案者である Trygve Reenskaug さんと共に「DCIアーキテクチャ」を発表しました。2010年、CoplienさんはGertrudさんとともに書籍『 Lean Architecture 』を上梓、トヨタ生産方式をソフトウェアアーキテクチャに適用するリーンアーキテクチャについて、DCIアーキテク
杉本 啓「2つのドメインモデル―DDDの含意」
Kei Sugimoto, “Two Domain Models - An Implication of DDD”, PHP Mentors, (December 20, 2015) ドメイン駆動設計（Domain-Driven Design: DDD）は、オブジェクト指向、デザインパターン、リファクタリングなど、ソフトウェア設計分野における幅広い知的遺産と交差します。それゆえ、ドメイン駆動設計は、ドメイン指向のアプリケーションソフトウェア開発に馴染むような仕方でこれらの知識資産を統合したものと見ることができます。 こうした見方は妥当でかつ生産的でもありますが、DDDの業績に対しては別の見方もあり得ます。それがこの短い論考のテーマです。 この文脈において、DDDは、「ソフトウェア設計」から、私たちが特別な思い入れを込めて「情報設計」と呼ぶものへの静かな出発として考えることができるかもし
「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～
増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本
Practical DDD #3: モデルの深さ
ドメイン駆動設計の「モデルの深さ」などについての考察、前回の続きです。 Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation前回の記事では、エリック・エヴァンスのドメイン駆動設計で書かれているモデルの深さというのは分かりづらいので、別の尺度としてモデルに表れる概念群の凝集度を考えてみてはどうか、ということに触れました。また、ユビキタス言語にあらわれる概念と概念が互いに関連しあい、述語でつながっていれば、パターンランゲージのようにドメインの知識を豊かに伝えることができるでしょう。 今回はドメイン駆動設計第1章の最後のストーリーで到達した「船荷証券（ふなにしょうけん）」というものから、モデルの深さについて考えてみます。 そもそも海運ドメインについて私には海運ドメインについての知識がありません。エヴァンス氏自身がそうだったのかはさておき、ドメイン駆
Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation
2014年4月6日に大阪で開催された第4回ドメイン駆動設計読書会＠大阪に参加しました。読書会の内容のまとめなどはWikiの方をご参照ください。今回は第1章の知識のかみ砕き、深いモデルと第2章ユビキタス言語の前半を読み、ディスカッションしました。ディスカッションで得られた気付きとこれまでに私が考えていたこと、ドメイン駆動設計の後半に出てくる「責務のレイヤー」などとのつながりについて、考察してみます。 モデルの「深さ」とは何かモデルに対して深いのか浅いのかについて、ドメイン駆動設計で何か客観的な指標が示されているわけではありません。あくまでエヴァンス氏の主観でしかないと言えますし、開発者が取り組んでいるドメインやコンテキストに依存するものでもあります。ドメイン駆動設計においては、モデルの深さを探求していくことが大きな目標の1つとされており、「深いモデル」という言葉が開発者同士の共通語になっては
Beyond MVC
PHP Advent Calendar 2013 - 6日目 昨日は@fivestrさんのComposerを使った簡単Travis CI設定でした。 TL;DR オブジェクト指向/MVCでうまく捉えきれていなかったものは何なのか？MVCから続くソフトウェアアーキテクチャーの「その先」は何なのか？Reenskaug博士を知っていますか？ WikipediaによればReenskaug博士は1930年生まれ。MVCという概念が世の中に送り出された論文『MODELS - VIEWS - CONTROLLERS (pdf)』は1979年ですから、49歳の時ということになります。1960年からソフトウェアを書き始め、1973年からオブジェクト指向でソフトウェアを開発しており、現在でも現役でソフトウェアの世界にいらっしゃいます（ex 2009年の講演）。「プログラマ歴42年 (* Clean Coder
状態ではなく、振る舞いをモックせよ
TL;DR GOOS本『実践テスト駆動開発』で触れられている「ロールをモックせよ」について、違った角度で解説ドメインモデルを豊かにすることでコードがシンプルになる例Mock Behaviors, Not Statesユニットテストを記述する際、テスト対象のオブジェクトが利用しているオブジェクト（依存オブジェクト、隣接オブジェクト）はモックオブジェクトにして、テストしたい状況をテストコード側からコントロールします。しかし、闇雲にモックを使ってテストを記述すれば良いわけではありません。今回は、モックが有効に機能するテストとはどういったものなのかを解説します。 サンプルコード簡単なサンプルで説明します。Extract Till You Dropのモデルと近いものを使います。グループ、メンバー、およびグループリポジトリがあります。グループオブジェクトはインメモリでは所属メンバーの情報を保持しておら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
