DDDにおいて、システムからは更新しないようなマスタデータもentityとしてrepositoryから取得してくるのが望ましいですか？ また、マスタデータをDBではなくenumで管理している場合、そのenumをentityとして扱うべきですか？ システムにおいてマスタデータを変更する契機が無い場合は可変ではないのでentityではなくvalue objectでしょうか？ | mond
DDDにおいて、システムからは更新しないようなマスタデータもentityとしてrepositoryから取得してくるのが望ましいですか？ また、マスタデータをDBではなくenumで管理している場合、そのenumをentityとして扱うべきですか？ システムにおいてマスタデータを変更する契機が無い場合は可変ではないのでentityではなくvalue objectでしょうか？ 一般論で答えますね。 システムから更新しないマスターデータをエンティティとしてリポジトリから取得すること そのマスターデータがビジネスロジックに関わる重要な概念を表現し、ドメインの一部として扱われるべき場合は、エンティティとして扱いリポジトリから取得するのが適切です。ただし、更新されないデータであれば、キャッシュの利用を検討するとよいでしょう 列挙型で管理しているマスターデータをエンティティとして扱うべきか 列挙型で管理さ
初めてDDDを使ってみて悩んだところ
研修でDDDを使ったサービスを作ってみることになったが、DDDを使うのが初めてなので同じような状況の人向けに悩んだところをメモしておこうと思う。 DDDとは DDD（Domain-Driven Design）とはドメイン駆動設計と呼ばれる設計方法の一種で、複雑なビジネスの要件をソフトウェアで上手く扱うためのアプローチとなっている。（DDDの詳しい説明などは以下を参照） DDDはドメイン（業界領域）の複雑さにフォーカスを当て、ドメインに精通しているドメインエキスパートと呼ぶ人の協力を得てシステム開発を行ってい行く。また、DDDではクリーンアーキテクチャ、ヘキサゴナルアーキテクチャなどのアーキテクチャと共に用いられることが多い。（今回作っているサービスではクリーンアーキテクチャを採用しているつもりだが、他のアーキテクチャとの違いが正直良く分かっていない） サービスの概要 ざっくりと説明すると、
5年間 Laravel を使って辿り着いた，全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころ
この記事は Laravel Advent Calendar 2020 - Qiita 最終日の記事です。 TL;DR DDD や "真の" クリーンアーキテクチャは， Web 業界における大抵の現場ではオーバースペックだし，導入しても全員がついてこれるとは限らない app/UseCases ディレクトリだけ切って，ドメインごとに単一責務なクラスを置くと使いやすいよ ActiveRecord 指向のフレームワークで Repository パターンを無理に導入すると死ぬので， UseCase で Eloquent Model の機能を使うことを恐れるな はじめに Zenn では初投稿です。日本の Laravel コミュニティではもうお馴染みのようで実はあまり顔を出していない（？） @mpyw と申します。オンラインサロンの火付け役となった Synapse が最初の仕事でしたが，就職後すぐ会社が
Laravel で DDD のレイヤードアーキテクチャを試す
まえがき 一年半かっちりとした設計を頑張ってみて、なんとなく形が見えてきたので、共有しようと思います。 タイトル通り、DDD の戦術の話がメインです。 いろんなデザインパターンを勉強しましたが、その中でも効果の解りやすいもののみを取り入れることで、迷い少なく方針を決めてこれました。 途中で設計変更は何度も行っていますし、設計変更することを前提に設計してます。 まだ悩んでる部分もいくつかあります。最後の方に書いています。 目的 設計するにあたって、以下の目的が達成できることを重視している。 業務知識があればプログラミングがわからなくてもなんとなくわかるようにする 部品ごとの役割を明確にする 部品を使い回しできるようにする 部品をテスト可能にする 状況に合わせて設計方針をどんどん変えていく 新しい書き方と古い書き方を混在させやすくする リファクタリングしやすくする 使わなくなった部品を簡単に削
Laravelでドメイン駆動開発（ddd） | DAブログ | DAホールディングス(エクスショップ&ガーデンプラス)
【デジタルアライアンス ハタケヤマ】 木附さん、バトンパス有難うございます。 娘の成長の速さに驚いて、近頃私も時の流れの速さを実感しています。 漫画といえば私が見ているのはアニメだけですが、ベタですが最近は私も鬼滅の刃にはまっています。 もしかすると漫画にも手を出すかも・・・現在検討中です。 さて、今回はPHPのLaravelフレームワークで、ドメイン駆動開発（以下ddd）を検討した話についてご紹介したいと思います。検討するに当たり、書籍「エリック・エヴァンスのドメイン駆動設計」(以下dddの書籍と呼称)だったり、Laravelでdddを検討した方がGitHubにアップされたサンプルプロジェクト等を参考に致しました。 LaravelはMVCのWebアプリケーションフレームワークです。言語はPHPとなります。そのまま使っても便利で簡単にWebアプリケーションの構築ができるのですが、Webアプ
効果的にDDDを導入するために気をつけるべきこと - Qiita
DDDはプロジェクトの期待に応えていますか？ この記事を読み始めたということは、あなたはDDDに興味を持っているか、またはDDDを実際に実践しているのでしょう。 最初に、あなたとDDDの関わり方について質問です。 あなたが実践しているDDDは、満足度の高いソフトウェアをユーザーに届けるのに、効果的に機能しているでしょうか？ またはこれからDDDを導入したいと考えているなら、どのようにDDDがあなたの問題を解決するか、イメージできているでしょうか？ どちらかにNoと答えたなら、この記事の内容が役に立つかもしれません。 DDDを学び始めるとき、我々エンジニアは技術的な面に興味が向きがちです。 レイヤードアーキテクチャ(基本だね!) クリーンアーキテクチャ(依存方向は内側だけに向くようにするんだ!) CQRSやイベントソーシングなどの手法(ストレージを分けるのか分けないのか...) モジュール分
DDD導入に踏み切れない方へ贈る「2層 + CQS アーキテクチャ(Flyweight DDD)」/Flyweight DDD
Flyweight DDD 軽量DDDを避けつつ軽量(Flyweight)にDDDを導入するためのアーキテクチャです。
Laravelで電子コミック書店をドメイン駆動開発(DDD)で実装した話
■ 概要 こんにちは。Applivマンガの開発の責任者の工藤です。 2018年1月ごろから電子コミック書店の開発をやって8月末に本リリースしました。(https://manga.app-liv.jp) CGM、無料漫画コーナー、有料漫画ストアの３フェーズくらいに分けて開発してきた中で色々試してきたことがあり、 その中からいくつかやって良かったものをリリース後の振り返りも兼ねて投稿したいと思います。 書いてたら結構長くなってしまったので今回はDDDまわりのみとして他の内容は次以降に書きます（たぶん）。 DDDの基本的な話はググればいっぱい出てくるので飛ばしています。 なので対象読者としてはDDD系の資料はざっと適当に斜め読みして大体わかってるけどめんどくさそうだなと思ってる人で、そういう人が本稿で「あーなんかきれいにまとまりそうだな試してみたいな」と思っていただけるとこれ幸いです。 ■ 実装
Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから
DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - little hands' lab
先日、メディアマックスジャパン様(以下、MMJ様)にお邪魔してドメイン駆動設計勉強会を開催してきました。そちらで質疑応答セッションがあり、実際にドメイン駆動設計で開発をしだしたタイミングで出てきた具体的な疑問について色々お答えしました。 おそらく多くの人が同じような疑問を持たれそうな内容だったので、MMJ様の許可を得てこちらでも紹介したいと思います。 コンテキストの分け方について DBを複数コンテキスト共通でつかっていいのか？ スキーマわけなくていいのか？ コンテキストごとにスキーマは最低限分けることをオススメしています。詳細は以下の記事をご参照ください。 little-hands.hatenablog.com 機能ごとに切る？ユーザ種別ごとにコンテキストわけるべきなのか？ コンテキストの切り方が正しいかどうか、どうやって判断すればいいか？ コンテキスト設計は、従えば作れるようなフローチャ
![DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/13f84b8758b38db7917b04405e41e71b2b5f7c43/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171221%2F20171221134405.png)
PHP Conference Kansai 2015
〜 大規模運用して初めて見えたアレやコレ (Elixir conf 2017発表資料) ニコナレが終わるのでこっちに退避。 オリジナル: https://niconare.nicovideo.jp/watch/kn2397
ドメイン駆動設計のメリットと始め方 ～ 1章「DDDへの誘い」
はじめに ドメイン駆動設計（DDD）とは、2003年にエリック・エヴァンス氏が『Domain-driven design』という書籍にて提唱したソフトウェア開発手法です。DDDを簡単に説明すると「顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法」です。具体的には、チームの共通言語である「ユビキタス言語」を用いて「ドメインモデル」を構築し、それをコードとして実装します。また大規模で密結合なシステムにならないように「ドメイン」と「境界づけられたコンテキスト」にてシステムを分割し、「コアドメイン」という最重要領域に集中して開発を行います。 ソフトウェア開発の課題とDDDが解決すること DDDの登場から10年以上が経ち、DDDは着実に普及しつつあります。DDDが普及してきている背景として、システム開発がますます多機能／複雑になり、ビジネス的にも敏速な変更が求められ
ドメイン駆動設計でビジネスを駆動する
ソフトウエア開発者はコードの設計と維持だけでなく、その経験を生かしてビジネスサイドに方向を与える能力も持ちつつある。ドメイン駆動設計(DDD)を使うことで、開発者は顧客の振る舞いを見つけビジネスの性質を変化させるための施策を推奨できる。 Jef Claes氏(http://jefclaes.be)はオフショアの開発者によって作られたアプリケーションを自分たちのチームで管理、拡張しやすいようにリファクタリングする仕事をした。新しいリファクタリングされたアプリケーションはオンラインギャンブルという氏の会社のビジネスのニーズにより整合的ではならない。氏はリファクタリングにDDDの方法論を導入した。集約、エンティティ、値オブジェクトを作り、状態の仕組みとしてイベントソーシングを採用した。結果、システムはビジネスの施策と会社の文化に変化を起こすような顧客の振る舞いを見つけたのだった。 InfoQは氏
FluxとDDDの統合方法 - かとじゅんの技術日誌
おはこんばんにちは、かとじゅんです。 久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。 さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。 Fluxって何？ まず基礎ということで、Flux i
大型フロントエンド開発におけるTypeScriptとDDD // Speaker Deck
All slide content and descriptions are owned by their creators.
日本と欧米ではPOJOの意義に対して微妙な解釈の違いがあるような気がする - 達人プログラマーを目指して
EJB2.1など、開発すべきクラスインターフェースに大きな制約のある侵略的なフレームワークに対してマーティン・ファウラーが広めた概念としてPOJO（Plain Old Java Object）という用語があることは、現在Java開発者であれば、周知のことかと思います。私は当時はEJBなど重量フレームワークの使用を推奨する立場の会社にいたので、POJOという言葉を知ったのは意外に遅く、2004年ごろエンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)などの書籍を通して初めて知りました。POJOという言葉には少なくとも以下の2つの意味がこめられていると考えています。 特定のフレームワークの規約を知らなくても設計できるため初心者でも簡単に理解できる 継承関係やデザインパターンの適用など本来のオブジェクト指向の設計を自由に行える 前者はP
DDD の Java EE 実装サンプル - Cargo Tracker を読み解く - Qiita
Cargo Tracker とは エリック・エヴァンスのドメイン駆動設計 で紹介されている様々なパターンを実際に使用して、有志が作成したサンプル Web アプリのこと。 DDD Sample Application - Introduction オリジナルは Spring Framework を使用している。 一方、この実装を Java EE 7 で置き換えたサンプルが公開されている。 Cargo Tracker この実装を読みながら、 DDD で紹介されている以下のパターンがどのように実装されているのかを確かめてみる。 レイヤ化アーキテクチャ エンティティ 値オブジェクト 集約 リポジトリ サンプルアプリを動かす ソースのダウンロード このページ の一番下に zip のリンクがあるので、そこからダウンロードする。 環境準備 以下のソフトウェアをインストールする。 JDK 7 以上 Mav
[ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第3回 大規模なプロジェクトへの適用 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 書籍『Domain-Driven Design』を紹介する本連載も、今回で最終回です。前回はDDDの第II部、第III部を紹介し、16のパターンによってドメインモデリングの基本的なアプローチを説明しました。今回は、残る第IV部から22のパターンを紹介します。 単一ドメインを扱ったドメインモデリングのノウハウは、前回までですべて終了です。第IV部「Str
![[ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場](https://cdn-ak-scissors.b.st-hatena.com/image/square/60719ddab4ac85c96737dd2e575f80b57b44d1c3/height=288;version=1;width=512/https%3A%2F%2Fwww.ogis-ri.co.jp%2Fotc%2Fhiroba%2Ftechnical%2FDDDEssence%2Fbook.jpg)
3週連続DDDその1 ドメイン駆動設計の基本を理解する
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Gamesatsushi061452
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/heynickc/awesome-ddd/blob/master/readme.md
