DDDに関する論の主戦軸を整理してみた（2020年版） - Qiita
各アクターのメンタルモデルと、複数のアクターが共用する"ドメインモデル"には情報構造上のギャップがある まず最初に、天重氏（@tenjuu99）による次の記事を参照する。 MVCとは何か ぜひ全編を読んでいただきたい。以降読んでいただいた前提で書く。 中盤《2. ドメインモデル》で、飲食店での複写式伝票の話をしている。下に記事中の図を引用させていただく。 この複写式伝票は、ある一つのドメインモデルを"実装"している、といえる。天重氏は、「この注文伝票をぼくが面白いとおもったのは、厨房の人とホールの人で情報構造が違っている点です。」と言っている。 ホールの人にとっての情報構造： ・席番号と料理の紐付けに関心がある。 厨房の人にとっての情報構造： ・料理を出す順番に関心がある。 （席番号と料理の紐付けに制約されずに、料理を出して行きたい。） そして、この複写式伝票は、 両者の情報構造の違い（と
原始のドメイン駆動設計はどこから始まったのか？ - Qiita
エバンスDDDでは説明できない 何もエバンス氏のドメイン駆動設計が時代に合わなくなったわけじゃないんです。 今日でもアジャイルとかスクラムとかとの親和性は高いと思っているんですが... 昔からいわゆる青本を見て「モデル駆動設計に偏っているなぁ」と思っていたんです。 で、最近、リファクタリングの観点リストをまとめる機会があって、その時にプログラミング言語の特性について色々と考えたんですが、その時に自然言語を含む「言語」と「モデリング」の関係を説明するには「ユビキタス言語」の解釈では全然足りなかったんですよ。 エバンス氏は「ユビキタス言語」について設計者がドメインエキスパートと直接話をしながらモデリングを行うためのツールと捉えていて、これが必要な理由を伝言ゲーム的な認識齟齬を防止するためとしています。 そのこと自体は良いのです。ただし、このユビキタス言語の言葉をプログラムの中でも使うことを推奨
ドメインモデルのつくり方 #5000dai
仙台で行われたレッツゴーデベロッパーZERO ONEで登壇した資料です。
DDD – Aggregate Roots and Domain Events publication – Paulo Clavijo
Implementing DDD in a traditional object-oriented style *, when an action over an Aggregate succeeds the state of the aggregate changes and one or multiple domain events are published. A Domain Event represents something that has happened in the domain. In the other hand if the action cannot be fulfilled a Domain Error is thrown as an exception by the aggregate. Publishing Domain Events from an Ag
Whirlpool Process of Model Exploration - Domain Language
Another violent water metaphor brought to you by the author of DDD! People often ask for more concrete guidance on how to explore models, especially in an Agile or Lean setting. The document you find here is Eric Evans’ attempt to capture in writing a process we have used with clients in various forms and settings for the several years. This is not a development process. It should fit within most
オニオンアーキテクチャにておいて、ドメイン層とアプリケーション層の責務はどう違うのか[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か - little hands' lab ドメイン駆動 + オニオンアーキテクチャ概略 - little hands' lab これらの記事で書いた通り、私はDDDのレイヤードアーキテクチャを決める際にオニオンアーキテクチャの用語を使っています。これまで色々な人に説明してきて、理解につまづきやすいポイントとしてレイヤの責務の話があったので、そこについて解説します。 一発で伝わりにくい(と思っている)定義 Onion Architecture Is Interesting - DZone Java こちらの記事で書かれている各レイヤの説明 Domain Layer Domain Model layer, where our entities and classes closely related to them e.g.
![オニオンアーキテクチャにておいて、ドメイン層とアプリケーション層の責務はどう違うのか[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/92f1d538c8b32d9cd85bcc5a8887455176717403/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171010%2F20171010194534.png)
Domain Storytelling
Build Better Business Software by Telling and Visualizing Stories Storytelling is at the heart of human communication—why not use it to overcome costly misunderstandings when designing software? By telling and visualizing stories, domain experts and team members make business processes and domain knowledge tangible. Domain Storytelling enables everyone to understand the relevant people, activities
ドメイン駆動設計 実践のための原則を4つ考えてみた - HITORIGOTO
『エリック・エヴァンスのドメイン駆動設計』（以下DDD本と呼ぶ）の原著出版から十数年が経過した今、DDD本に書かれている内容は、吟味されアップデートされるべき時が来ている。このアップデートに盛り込みたい内容を、4つの原則という形で考えてみた。 なお、以下では「EvansのDDD本の内容」と「ドメイン駆動設計というコンセプト」は重なる部分があるにせよ、それぞれが指す対象は異なるものだとしている。この違いは本文中で触れるが、表記として「DDD本」は本を指し、「ドメイン駆動設計」はコンセプトの方を指すようにしている。 DDD本とドメイン駆動設計 DDD本では、ドメイン駆動設計というコンセプトが導入された。ドメイン駆動設計というコンセプトは、ソフトウェアエンジニアの一般教養といえるほど、今ではその価値が認められている。同様のアイデアは、EvansがDDD本を執筆した時代ですら、すでに先人たちが口に
ドメイン駆動設計について DroidKaigi 2017 で登壇しました。
長らく Y.A.Mの雑記帳というブログでAndroidの技術情報を発信しています。最近はなかなか投稿できなくなってしまいましたが、それも仕事としてAndroidに関われているためです。Androidを触り始めたころはまだ学生だったので時間があったんでしょうね。 はじめて Android に関するエントリを投稿したのは 2009 年 5 月 24 日です。当時はJavaFXを触っていたので、NetbeansでAndroidをやろうとしていたようです。 当時のAndroidのバージョンは1.5、Fragment もなく、Support Library もなく、マルチタッチすらなく、ストアは Google Play ではなく Android Market という名前でした。 ここから2、3年くらいは、仕事でAndroid アプリを開発している人はもっぱらメーカーのプリインアプリを作っている方たち
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Eric Evans Says Domain-Driven Design (DDD) Isn't Done
DDD Europe 2018カンファレンス参加記
Wizards and warriors, part one
Eric Evans氏: ドメイン駆動設計は、以前より以上に妥当性を獲得している
ドメイン駆動設計のガイドライン: Capture - Embed - Protect
イベントベースのシステムにおけるプロセスマネージャー
microXchgマイクロサービスカンファレンス第１日 - DDD、プラットフォーム、企業への影響
エリック・エヴァンスのドメイン駆動設計 読書メモ5 - FLINTERS Engineer's Blog
DDDにおける重要なパターン
ソフトウェア開発に専門分野の重要性を取り戻す
Eric Evans氏はDDDが完璧主義者のためのものではないと述べた
