タグ

phpとdomain-driven-designに関するnabinnoのブックマーク (18)

  • Laravelとドメインモデルと永続化モデル @ laravel.osaka #12

    2017/11/15 laravel.osaka#12で使用したスライドです Laravelと永続化モデルのサンプルコード (Todo管理) https://github.com/n1215/lara-todo-persistence

    Laravelとドメインモデルと永続化モデル @ laravel.osaka #12
  • 「現場で役立つシステム設計の原則」批判 (1) ~何のために、「データとロジックを一体に」するのか?~

    増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 このが、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、このが指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 稿では、そのように私が考える理由について、3つの切り口からご説明したいと考えています: 何のために、「データとロジックを一体に」するのか?ポリモーフィズムは何のために?「ドメインモデル」とは何か?長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか?」について。 批判 (1) 何のために、「データとロジックを一体に」するのか?

    「現場で役立つシステム設計の原則」批判 (1) ~何のために、「データとロジックを一体に」するのか?~
  • 杉本 啓「2つのドメインモデル―DDDの含意」

    Kei Sugimoto, “Two Domain Models - An Implication of DDD”, PHP Mentors, (December 20, 2015)  ドメイン駆動設計(Domain-Driven Design: DDD)は、オブジェクト指向、デザインパターン、リファクタリングなど、ソフトウェア設計分野における幅広い知的遺産と交差します。それゆえ、ドメイン駆動設計は、ドメイン指向のアプリケーションソフトウェア開発に馴染むような仕方でこれらの知識資産を統合したものと見ることができます。 こうした見方は妥当でかつ生産的でもありますが、DDDの業績に対しては別の見方もあり得ます。それがこの短い論考のテーマです。 この文脈において、DDDは、「ソフトウェア設計」から、私たちが特別な思い入れを込めて「情報設計」と呼ぶものへの静かな出発として考えることができるかもし

    杉本 啓「2つのドメインモデル―DDDの含意」
  • Laravel5を使ってドメイン駆動設計で作るサンプルアプリ。 - Qiita

    Laravel5で変更に強いアプリケーションを作成する。 サンプルとして経費()を記録するだけのWebアプリケーションを作成。 日付、タイトル、価格、URLを1テーブルにしてMySQLへ格納。 ソースコード https://github.com/niiyz/Laravel-DDD Laravelインストール

    Laravel5を使ってドメイン駆動設計で作るサンプルアプリ。 - Qiita
  • 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

    Two Domain Models - An Implication of DDD
  • 「ドメイン駆動設計読書会@大阪」第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 公式アカウントに

    「ドメイン駆動設計読書会@大阪」第2回感想(モデルについて)
  • 「ドメイン駆動設計読書会@大阪」第3回感想

    最近入門致しましたプログラミング道場生 kawakawaです。 宜しくお願い致します。 ドメイン駆動設計読書会の第3回目に参加してまいりました。 今回も前回同様2グループに分かれ、それぞれディスカッションを行い、最後にその内容の共有を行いました。 レポート担当者さんによるまとめはwikiにまとめられています。 第3回「ドメイン駆動設計読書会@大阪」公式レポートWiki 個人的勉強になった点 ■1章の役割とは? 今回は第1章メインに議論したのですが、チーム1での発表にあった、 「この章の存在意義は、DDDの形や理想を示していて、目標にせよという意図を感じた」 という言葉に尽きると思いました。 最初、1章を読んだ時は、DDDを簡易に説明しているだけで、触りしか書いていないと思っていたのですが、上記のようにDDDの目標を提示しているという見方で意識してみると、確かに今後の章でキーとなる単語が多く

    「ドメイン駆動設計読書会@大阪」第3回感想
  • Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation

    2014年4月6日に大阪で開催された第4回ドメイン駆動設計読書会@大阪に参加しました。読書会の内容のまとめなどはWikiの方をご参照ください。今回は第1章の知識のかみ砕き、深いモデルと第2章ユビキタス言語の前半を読み、ディスカッションしました。ディスカッションで得られた気付きとこれまでに私が考えていたこと、ドメイン駆動設計の後半に出てくる「責務のレイヤー」などとのつながりについて、考察してみます。 モデルの「深さ」とは何かモデルに対して深いのか浅いのかについて、ドメイン駆動設計で何か客観的な指標が示されているわけではありません。あくまでエヴァンス氏の主観でしかないと言えますし、開発者が取り組んでいるドメインやコンテキストに依存するものでもあります。ドメイン駆動設計においては、モデルの深さを探求していくことが大きな目標の1つとされており、「深いモデル」という言葉が開発者同士の共通語になっては

    Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation
  • Practical DDD #3: モデルの深さ

    ドメイン駆動設計の「モデルの深さ」などについての考察、前回の続きです。 Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation前回の記事では、エリック・エヴァンスのドメイン駆動設計で書かれているモデルの深さというのは分かりづらいので、別の尺度としてモデルに表れる概念群の凝集度を考えてみてはどうか、ということに触れました。また、ユビキタス言語にあらわれる概念と概念が互いに関連しあい、述語でつながっていれば、パターンランゲージのようにドメインの知識を豊かに伝えることができるでしょう。 今回はドメイン駆動設計第1章の最後のストーリーで到達した「船荷証券(ふなにしょうけん)」というものから、モデルの深さについて考えてみます。 そもそも海運ドメインについて私には海運ドメインについての知識がありません。エヴァンス氏自身がそうだったのかはさておき、ドメイン駆

    Practical DDD #3: モデルの深さ
  • 「ドメイン駆動設計読書会@大阪」第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 公式アカウントに

    「ドメイン駆動設計読書会@大阪」第5回復習メモ
  • 「ドメイン駆動設計読書会@大阪」第6回感想

    プログラミング道場生 kawakawaです。 ドメイン駆動設計読書会の第6回に参加してまいりましたので、感想を報告させていただきます。 読書会の内容は、レポート担当者さんにより、wikiにまとめて頂いております。 第6回「ドメイン駆動設計読書会@大阪」公式レポートWiki 今回でDDDの第1部の範囲が終読致しました。 そこで、第1部全体での振り返りを行いたいと思います。 (2014/06/10 追記) から抜粋と記しているところを、抜粋元が不明瞭とのご指摘を頂きましたので、引用元箇所を明記しました。 ドメイン、モデル、ユビキタス言語の関係性DDD(第1部範囲)から記載されていた言葉を抜粋すると、 ドメイン 「第1部 ドメインモデルを機能させる」(中国世界地図の後) すべてのソフトウェアプログラムは、それを使用するユーザの何らかの活動や関心と関係がある。ユーザがプログラムを適用するこの

    「ドメイン駆動設計読書会@大阪」第6回感想
  • ドメイン駆動設計のリポジトリパターンをプロジェクトへ持ち込む時の話

    プログラミング道場生Hatajoeです。 ドメイン駆動設計読書会@大阪には初回から参加させて頂いています。 今回は、読書会で得られた知見を業務に導入する際の気付きをお話したいと考えています。 なぜリポジトリなのか話をする前に、なぜドメイン駆動設計な開発を導入しようと思ったのかの前提を説明させて下さい。 私は普段、チームでWebアプリケーションの開発を行っています。 チームには、自分を含めて3名のプログラマーが在籍しています。 言語はPHPで、CodeIgniterというWebアプリケーションフレームワークを使用しています。 現在、私達は以下の問題を抱えています。 ファットコントローラーコピペコードテスト無し既存機能の改修難易度が高く、機能追加でレガシーなソースが量産されるという悪循環です。 私は、これに対処するために、複雑で重複したビジネスロジックを切り出す必要があると考えました。 しかし

    ドメイン駆動設計のリポジトリパターンをプロジェクトへ持ち込む時の話
  • 「ドメイン駆動設計読書会@大阪」第8回復習メモ

    プログラミング道場生 kumamidori です。 「ドメイン駆動設計」読書会の第8回に参加しました。内容は、こちらのWikiにまとめられています。 この記事の前半では、復習として、関連、エンティティ、値オブジェクトについて、自問自答のQ&A形式でメモします。この道の先人から教えて頂いた内容が多いです。教えて下さった方、ありがとうとざいました。後半で、勉強会後に見つけた値オブジェクトのPHPサンプルを引用して紹介します。 Q&A 関連 Q. 情報と情報の関連は、(双方向ではなく)できるだけ一方向にすること、関連を限定することにより、 管理しやすくなる、という話があった。適切に関連を見出せるかどうかは、業務分析にかかっている。間違いなくそれを行うことはかなり難しいのでは? A. 一発ではできない。設計、実装しながらモデルを直していく(蒸留)。 関連は、業務のユースケースにより決まってくる。ユ

    「ドメイン駆動設計読書会@大阪」第8回復習メモ
  • Practical DDD #4: ユビキタス言語とモデル

    ドメイン駆動設計のユビキタス言語とモデルの関係性についての、個人的なメモです。 思考を図にする書籍「エリック・エヴァンスのドメイン駆動設計」の第2章で、ユビキタス言語の語彙について説明した段落があります。 ユビキタス言語の語彙には、クラスや主要な操作の名前が含まれている。また、モデルの中で明示されたルールについて議論するための用語も含まれている。この言語は、モデルが従うべき高次の構成原理(コンテキストマップや大規模な構造など、第14章と第16章で説明するもの)に由来する用語によって補完される。そして最後は、ドメインモデルに対して一般に適用されるパターンの名前によって、この言語は強化される。 エリック・エヴァンスのドメイン駆動設計 第2章 コミュニケーションと言語の使い方 ユビキタス言語 (p. 25) この文章が言わんとしていることを私の理解で図にしてみました。 この図は、上に挙げた段落の

    Practical DDD #4: ユビキタス言語とモデル
  • PHPメンターズ -> 第40回IT勉強宴会モデリング競演2でDDDのモデリングについて発表しました

    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 公式アカウントに

    PHPメンターズ -> 第40回IT勉強宴会モデリング競演2でDDDのモデリングについて発表しました
  • Debasish Ghosh氏のブログ記事「ドメイン駆動設計:可変性の管理」を翻訳しました

    ドメイン駆動設計が、今、世界的に盛り上がりを見せています。2016年1月には、Domain-Driven Design Europeが開催されるそうです。このイベントのスピーカー&ワークショップ講師の1人として、Jim Coplien氏の名前が載っています。Jim Coplien氏は、日だと、「組織パターン」の著者として、また、DCIアーキテクチャの人として有名ですが、ドメインエンジニアリングの研究者でもあります。 Eric Evans氏のDDDは、サブタイトルが、「ソフトウェアの核心にある複雑さに立ち向かう」となっています。複雑さとは何か、それを管理する技術とは何か、古くて新しい問題です。Jim Coplien氏の著作「マルチパラダイムデザイン」では、ドメインとは何か、どのように設計を行うべきかについて書かれています(残念ながら絶版です。) Debasish Ghosh(デバシッシュ

    Debasish Ghosh氏のブログ記事「ドメイン駆動設計:可変性の管理」を翻訳しました
  • PHPカンファレス2015 PHPメンターズセミナー「モデルを設計せよ!―ドメイン駆動設計を超えて」参加レポート

    2015年10月03日にPHPカンファレンス2015内で、ミニカンファレンスとして開催されたPHPメンターズセミナー「モデルを設計せよ!―ドメイン駆動設計を超えて」に参加してきました。 モデルを設計せよ!―ドメイン駆動設計を超えて視点PHPメンターズ 後藤秀宣 @hidenorigoto セッションのテーマは「視点」。いくつかの実例から、参加者が視点そのものについて実際に考えることができる体験的な講演でした。後藤さんのスライドに関しては公開は無しとのことです。このセミナーでは、この「視点」という言葉が全体を通じてのテーマになっていると思います。 特に印象深いのが「コップを空にする」話です。既にたくさんの知識を身につけた修行僧が、高名な僧侶のもとに学びに行きます。修行僧がひとしきり知識を披露した後、高名な僧侶は空の茶碗にお茶をそそぎ、そそぎ続けて、茶碗からお茶が溢れてしまってもそれをとめませ

    PHPカンファレス2015 PHPメンターズセミナー「モデルを設計せよ!―ドメイン駆動設計を超えて」参加レポート
  • 1