ドメイン駆動設計 第2章 ユビキタス言語を読みなおした - yoskhdia’s diary
社内交流会でLTをする機会があったので「ユビキタス言語」についてDDD本を再度読みなおしてみました。 speakerdeck.com 最近、「DDDは負け犬」みたいな話が少しバズりましたが、ユビキタス言語＝ユーザの言葉と解釈するのはあまりに勿体無いのではないかなと思います。 ユビキタス言語はより良い・深いモデルを探求するために必要なものです。 スライドの補足 第2章はスライドに書いたことよりも、もっと多くのことについて言及されています。 ここでは、それらの省略してしまった部分を補足しつつ、スライド構成の今ひとつだった部分を正したいと思います。 まず、第2章最初の一文 しなやかで知識豊富な設計を行うには、用途の幅広い、共有されたチームの言語と、その言葉を使った活発な実験が必要である。 – 書籍「ドメイン駆動設計」(p.24) 省略しようがないくらいに、この一文に詰まっているのですが、スライド
ユビキタス言語の作り方（ある一つの事例より） - Qiita
ある出版社プロジェクトにおける事例 出版社は「書籍」と「雑誌」を制作している。制作した「書籍」と「雑誌」は、取次（※出版業界における卸のような位置付けの業態）や書店へ卸す。 「書籍」には返品があり得て、また在庫は会計上資産として扱われる。「雑誌」は返品はあり得ず、また在庫は資産として扱われない。 「書籍」には「ジャンル」という販売管理上の分類がある。具体的には下記の通り。 一般書籍 企画書籍（※雑誌と書籍の中間的なもの、書籍だが決して重版しない） 音響・映像媒体付き（※特別扱い） 成人向け（※特別扱い） 販売管理観点では、「雑誌」もある種の一つの「ジャンル」として扱っている。販売管理観点での「ジャンル」は、つごう下記5つという認識。 一般書籍 企画書籍 音響・映像媒体付き書籍 成人向け書籍 雑誌 「取引条件」という売価、支払サイト等に関わる諸条件が、おおよそ取引先（＝取次や書店）×ジャンル
ユビキタス言語について - Qiita
こちら2つを読んで ユビキタス言語とは ソフトウェア開発チーム全体で作り上げる共有言語 ドメインのユーザーが使う用語とプログラムを構成する用語を一致させた言葉 プロダクトオーナー、開発者間のコミニュケーションを円滑にするためのようなもの ユビキタスとは 「満遍なく」とか「どこにでもある」という意味 ユビキタス言語の考え方 その業務自体が、どのような考えでどのように動くのか プロジェクトにとっての最善の用語か ユビキタス言語における変更は、モデルに対する変更である ドメインエキスパートは用語や理解を伝えるために適切かどうかに、開発者は設計を妨害する不整合さがないかどうかに着目すべき ユビキタス言語のスコープ チーム。チームによって話されて、チームが開発する単一のドメインモデルで表現される 「業界全体で」とか「全社的に」あるいは「世界中で」共通なドメイン言語を想定したものではない(ユニバーサル
ユビキタス言語についての知見を共有します - Qiita
この記事は、ドメイン駆動設計 #1 Advent Calendar 2018の10日目です。 ユビキタス言語は大事 DDDは分類手法の一つという側面があります。 分類の道具は境界づけられたコンテキストと、ユビキタス言語です。 境界づけられたコンテキストで、システムの対象業務を分類し、境界づけられたコンテキスト内部ではユビキタス言語で言葉を分類します。 個人的に、ユビキタス言語はDDDを実践する上でとても大事なテクニックだと思うのですが、何を指すものなのか、どういうメリットがあるものなのかわかりにくいために、初心者にとってはわかりにくいものかもなー、とも感じます。 そこでこの記事では、ユビキタス言語についての私の知見を書いてみます。ユビキタス言語についての学習の助けになれば幸いです。 ユビキタス言語とは何か？ ユビキタス言語の定義をする前に、「境界づけられたコンテキスト」について説明します。
実践DDD本 第12章「リポジトリ」～集約の永続化管理を担当～
実践DDD本 第11章「ファクトリ」～複雑な生成をユビキタス言語でシンプルに～ リポジトリとは 一般的に「リポジトリ」とはデータの「保管庫」を表します。ソースコードリポジトリであればGitやApache Subversionが有名ですが、DDDにおけるリポジトリは、エンティティや値オブジェクトから構成される集約の格納と取得を担当します。リポジトリは、クライアントへ集約を提供し、背後のデータベースとのやり取りを隠ぺいします。 通常、集約とリポジトリの関係は一対一になります。例えば「注文」の集約を利用したい場合「注文リポジトリ」を使用します。クライアント側はリポジトリのおかげで、物理的な構成（RDBなのか、NoSQLなのか等）を意識せずに、簡単に集約を操作できます。 リポジトリで集約を操作する流れ リポジトリはデータベースにアクセスしたり、ファクトリを利用したりします。その流れを見てみましょう
ドメイン駆動設計に関する何か - 日々常々
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
俺たちのドメイン駆動設計はこれからだ！
ドメイン駆動設計に取り組んだ事例をもとに以下の点について説明しました。 1. ドメイン駆動設計とは一体何か？ 2. どんなメリットがあるのか？ 3. ドメインモデルについて 4. 設計パターンについて 5. ドメイン層の隔離について
ドメイン駆動設計 実践ガイド
始めよう! ドメイン駆動設計＆マイクロサービス開発 ～C# と Azure Service Fabric で最高の DDD 開発を～貴志 上坂
境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [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)
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計の４つの基本活動、Springのプログラミングモデル、ドメイン駆動設計のためのSpringの使い方Read less
terasoluna.org
TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.8.1.RELEASE (2023-04-18) Japanese (HTML, ZIP) 5.7.2.RELEASE (2023-03-31) Japanese (HTML, ZIP) 5.7.1.SP1.RELEASE (2022-04-07) Japanese (HTML, PDF) 5.7.1.RELEASE (2022-03-31) Japanese (HTML, PDF) 5.7.0.SP1.RELEASE (2022-04-07) Japanese (HTML, PDF) 5.7.0.RELEASE (2021-03-31) Japanese (HTML, PDF) 5.6.2.SP1.RELEASE (2022-04-07) Japanese
ドメインモデルにおける集約ルートには、グローバル空間で一意なIDが必要？
ドメインモデル（ドメイン駆動設計）では、集約ルートにはグローバル空間で一意なIDを付けるべし、という情報を得ました。 DDD本にも、「（集約）ルートエンティティはグローバルな同一性を持つ」という記述があります。 ※ごめんなさい、電子書籍なのでページ番号分かりません。集約の不変条件についての記述です。 このことについて疑問がありますので教えて下さい。 例えば、プロジェクト管理アプリケーションを作っているとします。 ざっくりとした要件はこんな感じです。 プロジェクトを複数管理できる ひとつのプロジェクトは複数のタスクから構成される 人員を複数管理できる 人員は、色々なプロジェクトのタスクに割り振られる こうすると、集約としては「プロジェクト」と「人員」が出てくるかなと思います。 どちらも「プロジェクトID」と「人員ID」という、グローバル空間で一意なIDを付ければ良さそうです。 また、「タスク
「DDD パターンを活用した Laravel アプリケーション開発」を Laravel Osaka 2016 で発表しました。 - Shin x Blog
2016/10/19 に大阪で開催された Laravel Osaka 2016 にて、「DDD パターンを活用した Laravel アプリケーション開発」を発表しました。 会場の MOTEX さん。巨大スクリーンが 2 面あり、話しやすい環境でした。 発表資料 Laravel の具体的なテクニックに比べると抽象的な内容なので、どれだけ伝えられるか思案したのですが、聞いて頂いた方からのフィードバックや参加者アンケートでも概ね良い評価を頂けたので安心しました。 ValueObject については、さらに掘り下げて話せるテーマなので、これ単体でもまた話してみたいです。 Value Object は基本ですね | DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel https://t.co/ZzRTnt0tY6— 増田 亨． (@masuda220) O
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向では、モデリング（分析）、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。Read less
ドメイン駆動設計の学習曲線とブレークポイント
ドメイン駆動設計の実践力に転機が訪れる時。 チームがオブジェクト指向を体で覚えた時。 チームがインクリメンタルな設計を体で覚えた時。 チームでオブジェクト指向とインクリメンタルな設計を体で覚えるための指針。 QCon Tokyo 2016
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DDD�は間違いなくクソ
9.1. Spring Security概要 — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.3.1.RELEASE documentation
IDDD本から理解するドメイン駆動設計一覧
DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel
DDD実践(ベスト)プラクティス ~ドメインイベントとマイクロサービスと組織の関係~
