「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) ～ポリモーフィズムは何のために？～
増田亨氏の「現場で役立つシステム設計の原則]」批判の第２編です。 （２）ポリモーフィズムは何のために？オブジェクト指向の要件本書には「変更を楽で安全にするオブジェクト指向の実践技法」というサブタイトルが付与されています。オブジェクト指向が何かという点については、論者によって違いはあるものの、以下の３つが要件とされることには、多くの人が合意するでしょう。 カプセル化インヘリタンス（継承）ポリモーフィズム（多態）前回で明らかになったように、カプセル化は、オブジェクト指向とは独立にモジュール分割の指導原理としてデイビッド・パーナスにより提唱された「情報隠蔽」を敷衍したものです。オブジェクト指向の要件ではありますが、オブジェクト指向固有のアイデアではありません。 インヘリタンスは便利な機能ですが、コンポジションや移譲により代替できるので、オブジェクト指向の本質的な要件とは見做されなくなってきたかと
「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～
増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本
杉本 啓「2つのドメインモデル―DDDの含意」
Kei Sugimoto, “Two Domain Models - An Implication of DDD”, PHP Mentors, (December 20, 2015) ドメイン駆動設計（Domain-Driven Design: DDD）は、オブジェクト指向、デザインパターン、リファクタリングなど、ソフトウェア設計分野における幅広い知的遺産と交差します。それゆえ、ドメイン駆動設計は、ドメイン指向のアプリケーションソフトウェア開発に馴染むような仕方でこれらの知識資産を統合したものと見ることができます。 こうした見方は妥当でかつ生産的でもありますが、DDDの業績に対しては別の見方もあり得ます。それがこの短い論考のテーマです。 この文脈において、DDDは、「ソフトウェア設計」から、私たちが特別な思い入れを込めて「情報設計」と呼ぶものへの静かな出発として考えることができるかもし
Practical Symfony #28: Workflowerを使ったビジネスプロセスの管理
この記事はSymfony Advent Calendar 2015 25日目の記事です。前日の記事はqcmatsuokaさんの「SpBowerBundleのキャッシュエラーを解決する | QUARTETCOM TECH BLOG」でした。 WorkflowerはBPMN 2.0に準拠するPHP向けのワークフローエンジンであり、2条項BSDライセンスの下でリリースされているオープンソース製品です。Workflowerの主な用途としては、人間を中心としたビジネスプロセスをPHPアプリケーションで管理することが挙げられます。 この記事では、Workflowerを使ったビジネスプロセスの管理をSymfonyアプリケーション上で行うために必要な作業について示します。 PHPMentorsWorkflowerBundleによるSymfonyインテグレーションPHPMentorsWorkflowerBu
Two Domain Models - An Implication of DDD
Domain-Driven Design (DDD) intersects with a broad range of the intellectual heritage in the software design discipline including object-orientation, design patterns and refactoring. And as such, it can be viewed as a synthesis of these knowledge assets tailored towards domain-oriented application software development. Although this view is valid and productive, there could be another way of viewi
「ドメイン駆動設計読書会@大阪」第2回感想（モデルについて）
2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに
「ドメイン駆動設計読書会@大阪」第３回感想
最近入門致しましたプログラミング道場生 kawakawaです。 宜しくお願い致します。 ドメイン駆動設計読書会の第3回目に参加してまいりました。 今回も前回同様2グループに分かれ、それぞれディスカッションを行い、最後にその内容の共有を行いました。 レポート担当者さんによるまとめはwikiにまとめられています。 第3回「ドメイン駆動設計読書会@大阪」公式レポートWiki 個人的勉強になった点 ■１章の役割とは？ 今回は第1章メインに議論したのですが、チーム１での発表にあった、 「この章の存在意義は、DDDの形や理想を示していて、目標にせよという意図を感じた」 という言葉に尽きると思いました。 最初、１章を読んだ時は、DDDを簡易に説明しているだけで、触りしか書いていないと思っていたのですが、上記のようにDDDの目標を提示しているという見方で意識してみると、確かに今後の章でキーとなる単語が多く
Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation
2014年4月6日に大阪で開催された第4回ドメイン駆動設計読書会＠大阪に参加しました。読書会の内容のまとめなどはWikiの方をご参照ください。今回は第1章の知識のかみ砕き、深いモデルと第2章ユビキタス言語の前半を読み、ディスカッションしました。ディスカッションで得られた気付きとこれまでに私が考えていたこと、ドメイン駆動設計の後半に出てくる「責務のレイヤー」などとのつながりについて、考察してみます。 モデルの「深さ」とは何かモデルに対して深いのか浅いのかについて、ドメイン駆動設計で何か客観的な指標が示されているわけではありません。あくまでエヴァンス氏の主観でしかないと言えますし、開発者が取り組んでいるドメインやコンテキストに依存するものでもあります。ドメイン駆動設計においては、モデルの深さを探求していくことが大きな目標の1つとされており、「深いモデル」という言葉が開発者同士の共通語になっては
設定の仕様とは
設定の仕様をどう表現するのか、という趣旨の記事がありました。 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog;設定のクラスを作るとすっきりしそう - hitode909の日記 設定はDSLであるこのブログの過去記事（Pieceの中のSymfony #4: Configコンポーネント）やWEB+DB PRESS vol.75でも書いていますが、設定とはDSLです。ですから、設定の仕様というのはDSLの言語仕様として表現するのが適切です。DSLという抽象によって、内部でどのように問題が解決されるのかということと、設定の記述とが切り離されます。 PHPでの実装例(Symfony/Config利用)以降はPHPでの例になりますが、過去記事と同じくSymfony/Configコンポーネントを利用して、同じ設定ファイルを読み込むDSLを実装してみまし
BEAR.Sunday meetup #3 in Osaka 参加レポート
プログラミング道場生kumamidoriです。 PHPフレームワークの１つに、「BEAR.Sunday」があるのをご存知でしょうか。 リソース指向のOSSフレームワークで、郡山さん（@koriym）によって開発されています。 去年イギリスで行われたカンファレンス、「PHPNW2013」では、BEAR.Sundayのアーキテクチャを紹介するセッションがありました。 私は以前、旧バージョンにあたる「BEAR.Saturday」の方を仕事で使っていました。新しいBEAR.Sundayついては、初学者の状態で、さわる機会もあまりなかったのですが、気になっていました。2013年7月には、BEAR.Sunday meetup #2の主催をさせて頂いたこともありました。 そのようないきさつがあり、4月7日、BEAR.Sunday meetup #3 in Osakaを開催することになりました。 郡山さん
Practical DDD #3: モデルの深さ
ドメイン駆動設計の「モデルの深さ」などについての考察、前回の続きです。 Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation前回の記事では、エリック・エヴァンスのドメイン駆動設計で書かれているモデルの深さというのは分かりづらいので、別の尺度としてモデルに表れる概念群の凝集度を考えてみてはどうか、ということに触れました。また、ユビキタス言語にあらわれる概念と概念が互いに関連しあい、述語でつながっていれば、パターンランゲージのようにドメインの知識を豊かに伝えることができるでしょう。 今回はドメイン駆動設計第1章の最後のストーリーで到達した「船荷証券（ふなにしょうけん）」というものから、モデルの深さについて考えてみます。 そもそも海運ドメインについて私には海運ドメインについての知識がありません。エヴァンス氏自身がそうだったのかはさておき、ドメイン駆
「ドメイン駆動設計読書会@大阪」第5回復習メモ
2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに
DevLOVE名古屋「オブジェクト設計とリーン開発、その実践」に参加しました
2014年5月17日に名古屋で開催されたDevLOVE名古屋「オブジェクト設計とリーン開発、その実践」に参加してきました。その個人的な感想です。 向かい続けることが理想市谷さんのリーン開発のお話後半で、『リーン開発の現場 カンバンによる大規模プロジェクトの運営』に出てくる次の言葉を紹介されていました。 理想とはたどりつくべき場所のことではなく、 ありたい姿に向かい続けることなんだ！ Henrik Kniberg著『リーン開発の現場 カンバンによる大規模プロジェクトの運営』オーム社 2013年 p. 109 私個人もこの種の言葉は大好きです。そして、この種の言葉の背後にある価値観こそ、私がソフトウェアエンジニアとして、プロフェッショナルとして、持っていたいと常々感じているものでもあります。こういった価値観は、少なくともソフトウェアエンジニアとしての仕事の様々な局面で必要となる判断に、大きく影
「ドメイン駆動設計読書会@大阪」第6回感想
プログラミング道場生 kawakawaです。 ドメイン駆動設計読書会の第6回に参加してまいりましたので、感想を報告させていただきます。 読書会の内容は、レポート担当者さんにより、wikiにまとめて頂いております。 第6回「ドメイン駆動設計読書会@大阪」公式レポートWiki 今回でDDD本の第１部の範囲が終読致しました。 そこで、第１部全体での振り返りを行いたいと思います。 (2014/06/10 追記） 本から抜粋と記しているところを、抜粋元が不明瞭とのご指摘を頂きましたので、引用元箇所を明記しました。 ドメイン、モデル、ユビキタス言語の関係性DDD本（第１部範囲）から記載されていた言葉を抜粋すると、 ドメイン 「第１部 ドメインモデルを機能させる」（中国世界地図の後） すべてのソフトウェアプログラムは、それを使用するユーザの何らかの活動や関心と関係がある。ユーザがプログラムを適用するこの
Practical Symfony #24: ダイナミックなコンフィギュレーショングラマー
Symfonyフレームワークの動作を設定するコンフィギュレーションとその背後の仕組みは、Symfonyのアーキテクチャを支える強力な屋台骨となっています。この仕組みの応用例の1つとして、コンフィギュレーションエントリをダイナミックに定義する仕掛けを見てみます。 通常のコンフィギュレーション通常の静的なコンフィギュレーションは、バンドル内のDependencyInjectionディレクトリ以下にConfigurationクラスを用意し、そこで定義されたツリー構造に従って読み込まれます。コンフィギュレーションクラスの例は設定の仕様とは等を参照してください。この場合、あらかじめ固定のコンフィギュレーショングラマーがあり、それにもとづいてコンフィギュレーションファイルに設定を記述し、そのファイルの設定を読み込んでサービスコンテナが動作します。 アプリケーション開発の多くの場面ではこのような静的な定
ドメイン駆動設計のリポジトリパターンをプロジェクトへ持ち込む時の話
プログラミング道場生Hatajoeです。 ドメイン駆動設計読書会@大阪には初回から参加させて頂いています。 今回は、読書会で得られた知見を業務に導入する際の気付きをお話したいと考えています。 なぜリポジトリなのか話をする前に、なぜドメイン駆動設計な開発を導入しようと思ったのかの前提を説明させて下さい。 私は普段、チームでWebアプリケーションの開発を行っています。 チームには、自分を含めて３名のプログラマーが在籍しています。 言語はPHPで、CodeIgniterというWebアプリケーションフレームワークを使用しています。 現在、私達は以下の問題を抱えています。 ファットコントローラーコピペコードテスト無し既存機能の改修難易度が高く、機能追加でレガシーなソースが量産されるという悪循環です。 私は、これに対処するために、複雑で重複したビジネスロジックを切り出す必要があると考えました。 しかし
BEAR.Sundayチュートリアル・スクリーンキャスト
2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに
「ドメイン駆動設計読書会@大阪」第8回感想
概念的な同一と認識するもの 同一性は追跡できるようにしておくこと 同一性を間違えると、データ破損に繋がる
「ドメイン駆動設計読書会@大阪」第8回復習メモ
プログラミング道場生 kumamidori です。 「ドメイン駆動設計」読書会の第8回に参加しました。内容は、こちらのWikiにまとめられています。 この記事の前半では、復習として、関連、エンティティ、値オブジェクトについて、自問自答のQ&A形式でメモします。この道の先人から教えて頂いた内容が多いです。教えて下さった方、ありがとうとざいました。後半で、勉強会後に見つけた値オブジェクトのPHPサンプルを引用して紹介します。 Q&A 関連 Q. 情報と情報の関連は、（双方向ではなく）できるだけ一方向にすること、関連を限定することにより、 管理しやすくなる、という話があった。適切に関連を見出せるかどうかは、業務分析にかかっている。間違いなくそれを行うことはかなり難しいのでは？ A. 一発ではできない。設計、実装しながらモデルを直していく（蒸留）。 関連は、業務のユースケースにより決まってくる。ユ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
