「ドメイン駆動設計読書会@大阪」第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. 一発ではできない。設計、実装しながらモデルを直していく（蒸留）。 関連は、業務のユースケースにより決まってくる。ユ
Practical DDD #4: ユビキタス言語とモデル
ドメイン駆動設計のユビキタス言語とモデルの関係性についての、個人的なメモです。 思考を図にする書籍「エリック・エヴァンスのドメイン駆動設計」の第2章で、ユビキタス言語の語彙について説明した段落があります。 ユビキタス言語の語彙には、クラスや主要な操作の名前が含まれている。また、モデルの中で明示されたルールについて議論するための用語も含まれている。この言語は、モデルが従うべき高次の構成原理（コンテキストマップや大規模な構造など、第14章と第16章で説明するもの）に由来する用語によって補完される。そして最後は、ドメインモデルに対して一般に適用されるパターンの名前によって、この言語は強化される。 エリック・エヴァンスのドメイン駆動設計 第2章 コミュニケーションと言語の使い方 ユビキタス言語 (p. 25) この文章が言わんとしていることを私の理解で図にしてみました。 この図は、上に挙げた段落の
DIとサービスロケータの違い
DIとサービスロケータは、いずれもオブジェクトの構築と依存の解決という仕事を切り出すためのパターンです。ところで、この2つのパターンの違いを明確に説明できるでしょうか？ Pimpleでシンプルに正しくDIを理解する のコードは以下のようになっていました。 <?php require_once '../vendor/pimple/pimple/lib/Pimple.php'; // インフラ interface MailerInterface { public function send($body); } class SendmailMailer implements MailerInterface { public function send($body) { } } // ドメイン class NewsletterTransfer { protected $mailer; public
Practical Symfony #6: Symfony2の@apiアノテーションによる後方互換性の維持管理
この記事はSymfony Advent Calendar JP 2011の24日目の記事です。 速いペースでマイナーバージョンアップされるSymfony2Symfony2は、2011年7月に2.0がリリースされて以降、概ね月に1回のペースでメンテナンスリリースをしています。私自身が開発に携わっている案件でも、何度かこのようなメンテナンスリリースによるSymfony2本体のバージョンアップを行いましたが、直接的な問題はほぼ発生していません。フレームワークの更新というと、マイナーバージョンアップでさえ事前に変更点をしっかり調査し、適用しても問題がないという調査・判断が必要でした。Symfony2でももちろん事前に変更内容を調査することは必要ですが、Symfony2側で後方互換性が維持されるルールが導入されており、上手く機能しているようです。 この「後方互換性を維持するルール」の中心となるのが「
Practical Symfony #25: Routerを拡張してURLのサブディレクトリを横断的に処理する
Symfony Advent Calendar 2014 (Qiita) 4日目 前(12月3日 ) 次(12月5日) Webサービスで、ユーザーのアカウントごとにサブディレクトリを割り当てたいとします（最近はユーザーアカウントごとにサブドメインを割り当てる方が主流かもしれませんが）。例えば次のような形です。 トップページ http://example.com/ユーザー hidenorigoto のコンテンツ http://example.com/hidenorigoto/profilehttp://example.com/hidenorigoto/report/20141124ユーザー someone のコンテンツ http://example.com/someone/profilehttp://example.com/someone/report/20141124このような形をとるシス
ドメインモデルのための型「Domain Kata」を使ってみました
Symfony Advent Calendar 2014 (Qiita) 6日目 前(12月5日 )次(12月7日 ) 「Domain Kata」について学んだことを書いて、Symfony2 サンプルアプリケーションでの使用例を紹介します。 Domain Kata についてDomain Kata Kata for domain models 公式 README の内容を日本語に訳すと下記となります（バージョン 1.2 現在）。 Domain Kata は、プロジェクトがモデルベース開発を実践するために、ドメインモデルの「型」を提供します。 モデルベース開発というのは、たとえば、ドメイン駆動設計、ジェネレ−ティブプログラミングといった手法を指します。 Domain Kata を使うことで、モデルの識別が容易になります。パッケージ構造を設計しやすくなります（「Model」パッケージをライブラリ
Practical Symfony #26: PHPMentorsPageflowerBundleを使ったページフロー定義と対話の管理
Symfony Advent Calendar 2014 (Qiita) 10日目 前(12月9日)次(12月11日)PHPMentorsPageflowerBundleは筆者が開発したSymfonyアプリケーション向けのページフローエンジンです。特徴としては、以下のものが挙げられます。 アノテーションによるページフロー定義対話の管理アクセス制御されたアクション対話スコープのプロパティ対話開始直後に実行されるユーザー定義メソッド複数のブラウザーウィンドウまたはタブのサポートPHPMentorsPageflowerBundleを使うと、コントローラーに断片的に埋め込まれたページフローに関するコードを明示的な定義で置き換えることができます。また、対話と対話スコープのプロパティの導入によってコントローラーの状態管理コードを大幅を削減することができます。 では、早速コードを見てみましょう。以下はS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
