【スライド・動画あり】PHP Conference 2018 で Laravel × レイヤードアーキテクチャについて発表しました - WILLGATE tech blog
10 月から開発グループ直下の所属となりました。岡田（okashoi）です。 先日 12/15（土）に開催された PHP Confernece 2018 にて「Laravel × レイヤードアーキテクチャを実践して得られた知見と反省」というテーマで登壇させていただきました。 PHP Conference 2018 の様子 PHP Conference 2018 のテーマは「GROWTH」 今年は「GROWTH」をテーマに合計 38 のセッション + 10 を超える LT がありました。 どのセッションも興味深い内容であり、当日の来場者はおよそ 1000 人にものぼったそうで、たいへん盛り上がりました。 当日の盛り上がりは twitter からも見て取れると思います。 twitter.com 発表内容 Laravel × レイヤードアーキテクチャを実践して得られた知見と反省 / Practi
DDDとコードとしての正しさ - pospomeのプログラミング日記
ドメイン駆動設計 #1 Advent Calendar 2018の14日目を担当する@pospomeです。 今回はDDDとコードとしての正しさについて書いてみようと思います。 DDDは設計手法である コードとしての正しさ コードとしての正しさを見失う ユースケースの日本語を"そのまま"コードに落とし込もうとする 無駄にオブジェクト同士の結合度を上げる RubyのActiveRecordの正しさ コードとしてのメリット、デメリットを具体的に考えて解決する まとめ DDDは設計手法である DDD = ドメイン駆動設計 ですよね。 "設計"という単語が付いていることから分かる通り、DDDはあくまでソフトウェアにおける設計手法です。 そのためDDDの成果物は"コード"であり、DDDの目的は"コードの可読性を上げること"であると自分は考えています。 DDDが持つ"ビジネスを理解する", "ドメインを
「DDD」にまつわる諸課題の整理 - Qiita
DDD的なことを今後進めていく上で、自分として課題としている論点をまとめてみた。あくまで私の現時点での理解度を前提に、そこでの個人的課題感を取り纏めてみたものなので、不足や誤りや過剰が多々あるだろうがご容赦を。そして、アドベントカレンダーの初日、続く議論の礎となり、3人の賢者24人の荒ぶる者によってベツレヘムの星が見出されることをただ願うのである。 ◇ あらまし DDDのいわゆる戦略の言う“広義のドメイン”と、戦術パターンにおける“狭義のドメイン”。この二つの用語は、実のところ「異なる境界付けられたコンテキストに属する語彙」として扱った方がよいのではないか？ 参照系と更新系は、その本質として非対称性があって、参照系向けの新たな戦術パターンが必要なのではないか？ 「コンテキスト」は、強く分離する上位階層から緩く分離する下位層まで、多段階の階層構造に在ると捉えるべきではないか？ （「3.」を前
ドメインオブジェクトを中心としたClean Architecture のためのレイヤー構成 - Qiita
ドメインオブジェクトを中心としたClean Architectureは、どういうレイヤー構成にするとよいか、簡単にまとめてみた。 イメージ たぶん、こんな感じになるはず。通常は円状に表現するが、わかりにくいので層状に書いてみた。 赤い部分の層は、直接依存の方向が上から下です。グレー部分の層は、契約だけが定義された独立した層で、ユースケース層やインターフェイス層から依存できるものとします。 インターフェイス（アダプタ）層 内外とのデータ形式の変換が主な役割 コントローラ、プレゼンター（内部から外部へデータ形式を変換する責務）,ゲートウェイ(外部と通信する責務。DBやRPC) ユースケース層 アプリーケーション層ともいう アプリケーション固有のビジネスルールをカプセル化する ドメイン層 Clean Architecture本では、中心にはエンティティとだけ書かれているが、DDDでは中心はドメイ
Laravel5のアーキテクチャから学ぶより良いクラス設計 - Qiita
はじめに ウェブアプリケーションフレームワークのクラス構成にはさまざまなバリエーションがありますが、どれも様々なデザインパターンを駆使し、素晴らしいクラス構成になっています。 今回、じっくりフレームワークのソースコードを読むことで、少しでもいいクラス設計について学べるといいなぁと思い、このような企画を思いつきました。 PHP には様々なウェブアプリケーションフレームワークがあり、それぞれに特徴がありますが、今回は、近年突出して注目されている Laravel を取り上げます (いずれ他のフレームワークでも試してみたいです)。 環境 PHP 5.6.9 Laravel 5.2 やったこと Eloquent (Active Record) と DBファサード (Query Builder) の使い分け、ついでに Repository について Dependency Injection と Ser
オブジェクト指向をより理解するために実際に書いて解説する
はじめに こんにちは、yoship1639です。 普段はゲームエンジンを用いない個人ゲーム開発を行っております。 本記事は、オブジェクト指向がいまいち理解できない人、なんとなく理解はしたけどプログラムに落とし込めない人を対象に、 簡単なプログラムをオブジェクト指向満載で実際に書いて、理解を深めてもらおうと思い記述しています。 プログラミング言語は普段私がよく使うC#で記述しますが、オブジェクト指向は言語の壁を越えて利用できる概念ですので、 言語の記述ではなく、その記述の持つ意味を昇華させ俯瞰的に見ていただけると、より理解が進むのではないかと思います。 本記事の背景・目的 オブジェクト指向に関する記述はとても増えてきました。しかし、一部を除いては理解を妨げる解説をしている記事が多数見受けられます。 具体的な用語の説明をならべても、抽象化し過ぎた解説しても、プログラミングに落とし込むことはでき
ドメインモデル貧血症の処方箋 - まめログ
以前のプロジェクトで、ドメインモデル貧血症なプログラムに悩まされたので、学んだことを書いてみます。 ドメインモデル貧血症とは オブジェクト指向におけるアンチパターン。 振る舞いとデータが分かれてしまっており、手続型の設計・実装になってしまう状態。 詳しくは以下のURLで。 Martin Fowler's Bliki in Japanese - ドメインモデル貧血症 自分なりの理解では、ドメインモデル=エンティティクラスと思ってます。 試しに以下のような従業員クラスでドメインモデル貧血症を考えてみたいと思います。 /** * 従業員クラス */ public class Employee { private int employeeId; private String familyName; private String firstName; private double weight; p
戦術的DDD基本原則まとめ - Qiita
DDDを実践し始めてまだ日が浅いので、ドメインモデリング中に 細かい原則がすぐ出てこなくて迷うことがあります。 そこで、「エリック・エヴァンスのドメイン駆動設計」から 第2部「モデル駆動設計の構成要素」を中心に、モデルを表現する各要素（パターン）の 基本原則をまとめてみます。 第5章「ソフトウェアで表現されたモデル」 関連 ENTITIES（エンティティ） VALUE OBJECTS（値オブジェクト） SERVICES（サービス） MODULES（モジュール） 第6章「ドメインオブジェクトのライフサイクル」 AGGREGATES（集約） FACTORIES（ファクトリ） REPOSITORIES（リポジトリ） 関連 関連をたどる方向を強制する 限定子を付けて多重度を減らす ドメインにとって本質的でない関連を除去する 本質的でない関連が除去された結果、残った関連はそのドメインの特徴を表す E
DDD超入門(後編) - Domain-Driven Designの適用Step - エンタープライズギークス (Enterprise Geeks)
前編ではDDDの概要についてふれたが、後編ではDDDの適用Stepを3つのStepに分けて紹介する。 まずStep1として、アプリケーションに登場しうる概念を抽出してドメインモデルで表現する。 次にStep2として、各ドメインの概念を深掘りしてソフトウェアとしてどう表現するかにについて紹介する。 最後にStep3でドメイン部品の仕上げとDDDの恩恵ついてふれていく。 Step1: ドメインモデルによる表現 DDDでは機能やユースケースに加えて、その裏に潜んでいる「概念」を抽出する必要がある。そのため、DDDを導入するにあたってアプリケーションに登場しうる概念を整理した「ドメインモデル」がまず必要となる。全体のコンテキストを整理して、該当のドメインモデルを描くことがDDDの最初の1歩となる。 例として、よくある一般的な受注管理の簡単なドメインモデルをあげる。 「顧客」からある「商品」の「注文
[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance ｜ Developers.IO
こんにちは。プロダクトグループのshoito(しょいと)です。 9/26(水)に開催された レガシーコードにドメイン駆動設計で立ち向かった5年間の軌跡 に参加してきたのでレポートします。 当日のtwitterのハッシュタグ#DDDAllianceのツイートがTogetterでまとめられています。 BIGLOBEにおける、5年間のDDDへの取り組みと今後について ビッグローブ株式会社 西 秀和さんより 30年間、事業を支えてきた業務システムをDDDで刷新する。 そのためには、組織的、エンジニアのレベルなど多くの問題があります。 その壁をどう乗り越えたのか？ そして、壁の向こうで得た恩恵とは何のか？ 5年という期間を経て、得ることのできた気づきや組織的な変化をお伝えしたいです。 アジェンダ DDD導入に至るまで 導入時の苦労 導入による効果 今後の目標 BIGLOBE販売システムについて、DD
![[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance ｜ Developers.IO](https://cdn-ak-scissors.b.st-hatena.com/image/square/ca7afdf4d75f0e7f31dad0cb5f52f15acfa79209/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F09%2FDDD_blue.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2017/03 版 DDDパターンを活用した Laravelアプリケーション開発/201703-ddd-with-laravel
世界でいちばんわかりやすいドメイン駆動設計
