境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
境界づけられたコンテキストとは 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界づけられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界づけられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界づけられたコンテキスト ・境界づけられたコンテキストをどう実装に
![境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/6bb65ba88fd34a29140629a2f7085b6e005c2663/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171128%2F20171128072027.png)
ドメイン駆動設計の源流のPofEAAを読んでみる | フューチャー技術ブログ
最近、ドメイン駆動設計(以下DDD)とかそのあたりを読みこんでいる人から、DDD本の読み方を教えてもらいました。ここではDDD本はエリック・エヴァンスのドメイン駆動設計の方を参照しました。 @katzchang さんから教わったのは「DDDはパターンランゲージの形式を意識してるよ」ということでした。ただし、きちんとしたパターンランゲージの形式になっておらず、記述が著者のものになってるので、読者は注意して読む必要があるのかもとのことです。 @ryoaitaさんから教わったのは「DDDはエンタープライズアプリケーションアーキテクチャパターン(以下PofEAA)を下敷きにしている本だよ」ということでした。 DDDももう時代的にはかなり古い本です。自分で読んだ限りは全然好きになれなくて、でもきっと何かあるはずだと3-4冊読んでみましたが感想は変わらずでした。ユビキタス言語も「当たり前のものを先頭に
ドメインを純粋に保つ (レガシープロジェクトの改善活動について) (1)
機能追加や修正を継続的に行なっているPHPの小規模レガシープロジェクトを、独りで運用しながら改善に取り組んでいます。何処を目指して、どうゆう方針で改善を行なっているかを纏めてみようと思いました。継続して運用していくプロジェクトであれば、新規プロジェクトでも応用できる考え方として参考になるのではないかと考えています。主に以下にリストアップした技術書を読んで、学んだことを現場で活かそうとしている活動の記録でもあります。 セキュア・バイ・デザイン テスト駆動開発 現場で役立つシステム設計の原則 単体テストの考え方/使い方 結論は「ドメインを純粋に保つ」というのをスローガンにするこで、アプリケーションの健全化しようと試みています。純粋な「ビジネスロジック」を、ドメインという特別な領域に隔離しつつ、純粋な単体テストで保護しながらアプリケーションの継続的な改善活動を楽で安全にしたいと考えています。 ビ
【PHP】DDDにおける値オブジェクトを変更したい時のメモリ周りについて調べた - BASEプロダクトチームブログ
こんにちは！ バックエンドエンジニアの高町咲衣です！ この記事では、PHPでDDD（ドメイン駆動設計）を扱う際に気になる「値オブジェクトを更新＝作り直した時のメモリ周りの挙動」について調査した結果をまとめています。 値オブジェクトは不変である DDDの文脈における値オブジェクト（ValueObject）の特徴の一つとして、不変（immutable）であることが挙げられます。 値オブジェクトは「値を表現する」オブジェクトであり、例えばプリミティブな値であるint、stringなどと同じように取り扱うべきだとされています。 // プリミティブな値を用いた、ごく一般的な感覚のコード例 $number = 1; // 値をセットする $number = 2; // 値を入れ直す var_dump($number); // 2 var_dump($number === 1); // false //
DDDの正体は実装パターンとモデリングの組み合わせ - パンダのプログラミングブログ
PoEAA を通して DDD の半分を理解する マーティン・ファウラーの PoEAA を読んでから、DDD のことを考え続けている。今まで DDD の話題はあえて避けてきた。分厚く難解な書籍、増えるコード量、教祖とその信徒たち（MV）、全てをその視点から解釈しようとする試み、少しでも間違えたら求められる自己批判、無知な者に対する SNS 上のオルグ、いつまでも出てこない総括、それでも信じるものは救われる。「一匹の亡霊がIT界隈を徘徊してる。DDDという亡霊が...」 まあ早まらないでほしい。何も DDD こき下ろそうというわけではない。自分の実力不足が主な原因と思い、深入りする前から「わからないもの」と決めつけていた DDD は、PoEAA というライトに照らされてその姿を私の前に姿を表し始めた。それは亡霊ではなく、確固たる手触りのある実体（Entity）だったのである。 PoEAA は
Software Design 2023/2 第１特集：ドメイン駆動設計入門を読んだ！ - そこに仁義はあるのか(仮)
増田さんから Software Design 2023/2 を献本いただきました！ 第１特集はドメイン駆動設計入門で、50ページとすごいボリュームで読み応えたっぷりでした！ Software Design (ソフトウェアデザイン) 2023年2月号 [雑誌] 技術評論社Amazon 🙆♀️ こんな人にオススメ ドメイン駆動設計の基本と、そこからさらに一歩進んだ内容を幅広く学べます。 何かの書籍で学ぶ前にドメイン駆動設計の考え方をまずは知りたいという方にオススメです！ 説明の中でクリーンアーキテクチャやマイクロサービスについて言及されている箇所もあり、この本を読むことで興味の幅を広げることができるとも感じました。 現場での経験に基づいた事例の紹介もあり、コンテンツとしてとても濃いものになっています！ まずはこちらの特集でどんな考え方があるのかを把握した上で、エヴァンス本や増田さんの「現場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モノリスにおけるビジネスロジックの設計 ～アグリゲートパターン～ / aggregate-pattern-for-domain-modeling-on-monolithic