僕の認識と頂いた意見をマージしてみた

ドメイン層:
業務上のルール、制約条件の実現
(判断、計算、加工など)

アプリケーション層:
ドメイン層で許可された操作を組み合わせることによるユースケースの実現(判断、計算、加工以外の処理の指示や進行管理 / モデルの生成と利用、永続化と再構築依頼)
— 松岡@DDDブログ書いてます (@little_hand_s) October 25, 2018

speakerdeck.com

DDDの集約とエンティティが理解できないという質問されたことある。リポジトリはエンティティと一対一につくるんですか？みたいな質問も。僕も最初混同してたのでわかる。リポジトリはエンティティではなく集約と一対一です。エンティティは、集約の中に一つ以上ある場合がありますから
— かとじゅん (@j5ik2o) November 1, 2018

DDDではアプリケーション層にUnit Of Workを定義して解決という話だったかな。個人的には集約がトランザクション境界と一致。複数の集約を跨ぐ場合でもトランザクション境界はまとめないことが多いです。 https://t.co/rd2H6leJMH
— かとじゅん (@j5ik2o) November 1, 2018

契約プログラミングを真面目に勉強すると、クライアントのコードが、サービスの実装ではなく、サービスが実装する契約に依存できるようになりますね。難しい表現だけど。こうすることで、お互いに契約を維持できれば、サービスの実装はいかようにも変更できます。
— かとじゅん (@j5ik2o) November 8, 2018

ドメインオブジェクトを中心としたClean Architecture のためのレイヤー構成 #DDD - Qiita

speakerdeck.com

ユースケースをロバストネス分析してアクターとバウンダリとエンティティとコントロールに整理するのは確かにわかりやすいかもなー。
ただコントロールをエンティティの振る舞いとするよりアクターの振る舞いとしがちなのでアクターをドメインモデルにしないという縛りが重要なのかな？ #scala_ks #s1
— がくぞ (@gakuzzzz) November 10, 2018

分析の過程で得られるのがドメインモデル(問題や課題を解決する考え方を表す何か)で、それを実装に反映したのがドメインオブジェクトだと解釈している。DDDは単一モデルではあるけど、実装の細部は表現が異なることもあるので、この言葉使いが役に立つこともある。
— かとじゅん (@j5ik2o) December 18, 2017

最近はこんな感じです

1.企画、デザイナーが画面デザイン作る
2.エンジニアがモデリング(ユースケース図、ドメインモデル図書く)
3.ここで不明な点を企画と確認して固め、ドメインモデル図などに反映
4.実装開始。DB設計と実装は分担したり一人でやったり#ドメイン駆動設計 https://t.co/Wm9GPxPvAf
— 松岡@DDDブログ書いてます (@little_hand_s) April 18, 2019

第3回 -ドメイン駆動設計のためのオブジェクト指向プログラミングハンズオン"に参加してきた！ - desi-gneer(designer_engineer)

speakerdeck.com

ドメインモデルには順序依存性がないように作る。順序依存性が必要なものはアプリケーション層(サービス)に書く
— 石◯王もちだ (@mike_neck) March 28, 2017

昨日、共有カーネルにするか否かという議論をした。安直に選択すると利害関係者間で合意を取るコストが跳ね上がるって話した。あと、増田さんの記事
「Shared Kernel パターンは、たぶんアンチパターン」を読むと参考になるかもしれません。https://t.co/putgpy7FJh
— かとじゅん (@j5ik2o) June 15, 2019

純粋に計算する型は、IO型に依存してはいけない。
IO型は計算用の型に依存してよい。
三層+ドメインモデルのアーキテクチャは、計算用の型のライブラリであるドメイン(の計算)モデルとIO型で組み立てる他の層を強い意志を持ってに分離するための枠組み。
— 増田亨． (@masuda220) December 3, 2018

結果整合性がどうしてもコストが大きくて、同一トランザクションでやりたい場合、という前提で考えてみました。

5. パターン3の拡張で、ユーザー数の制約を管理する別の集約を作る
企業の中に他集約の数に応じたカウントを持つのはやはり違和感があるので、その部分だけ切り出してしまう。(続)
— 松岡@DDDブログ書いてます (@little_hand_s) December 2, 2018

集約の境界と整合性問題に関する感想 #DDD - Qiita

確かに、これは良いかも。
私見としてアプリケーション層はユースケース記述に近い表現にするとよいという整理をしていて、かつアプリ層は再利用が少ないので部品となる機会も少ない。
全角文字によるIDEの入力補完をする機会も少ない。
イメージはテストユニットに近い感じの扱い。 https://t.co/eTdO72Ma5N
— Yamashita (@_vermeer_) 2021年2月4日

ユースケース

ドメインモデルの根拠とドメインモデル貧血症の対策について - kubell Creator's Note

UMLを描こう – Vol.6 ロバストネス図からシーケンス図を描く - アシアルTechブログ

https://t.co/gtPAwTCNfw
質問者がアメリカの方であるとして、英語圏の人にとって日本人のいう「条件」と「状態」の違いは質問に値する違いってことと想定。
— Yamashita (@_vermeer_) 2017年12月16日

ユースケースを呼び出すユースケースって、ありなのかぁ。
ダメだと思い込んでた。
個人的には大きなショック。
ユースケース記述の実装をServiceとすれば設計と実装の乖離がなくなるのかなぁ。
でもそれはトランザクションスクリプト的な感じで悪手なのかなぁ。
— Yamashita (@_vermeer_) 2017年12月16日

CQRS

Ladder of cqrs+es from Masaki Toyoshima

www.slideshare.net

#jjug_ccc 僕がDDDを勉強したりDomain Event使ってみたいと思ったりKafkaでCQRSの素振りをしている背景と現状 - Mitsuyuki.Shiiba

DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話 from Koichiro Matsuoka

www.slideshare.net

CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも？」 | POSTD

本来一つの集約としてモデル化されるべき複数のエンティティが集約として勘違い実装。リポジトリも別々。でもアプリケーション層で同一トランザクション。これ一つの集約では？
オブジェクトをバラバラに砕くと有益な不変条件がなくなる→振る舞いもアプリケーション層に流失する
— かとじゅん (@j5ik2o) November 15, 2018

Event

ドメインイベントを設計する - yoskhdia’s diary

speakerdeck.com

主にメール送信とかで役に立ってるかな。疎結合だからテスト書きやすいし、spring-dataにはこの仕組みが用意されてるので導入しやすい https://t.co/PVFWwzLOU5
— Yuki YOSHIDA (@sis_yoshida) December 12, 2017

www.youtube.com

書籍

現場で役立つシステム設計の原則変更を楽で安全にするオブジェクト指向の実践技法 [ 増田亨 ]

価格: 3234 円
楽天で詳細を見る

vermeer.hatenablog.jp

ドメイン駆動設計複雑さに立ち向かう from 増田亨

www.slideshare.net

現場で役立つシステム設計の原則 from 増田亨

www.slideshare.net

ドメインロジックに集中せよ〜ドメイン駆動設計 powered by Spring from 増田亨

www.slideshare.net

持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP #DDD - Qiita

ドメインオブジェクトの責務について #DDD - Qiita

トランザクション スクリプト

ユースケース(アクション)中心にオブジェクト(メソッド)を組み立てるのがトランザクションスクリプト

いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ

むむっ、私の思考はトランザクションスクリプトの可能性大かもしれない。

実装

DDD の Java EE 実装サンプル - Cargo Tracker を読み解く #オブジェクト指向 - Qiita

ドメイン駆動設計: IDDDに登場するサンプルコードのModule構成をまとめてみた #DDD - Qiita

2.4. アプリケーションのレイヤ化 — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.3.0.RELEASE documentation

ドメインモデルをコードへ落とす〜あなたのクラスは、どこから？〜 #勉強会 - Qiita

GitHub - system-sekkei/isolating-the-domain: architecture sample using : Spring Boot gradle, Spring MVC, Thymeleaf, and MyBatis

構成

実装サンプルの中で個人的に一番しっくりくるのはTERASOLUNA。
プロジェクト分割については好みの思考。

ValueObjectは、どの層からでも呼び出して良いフラットでパブリックなものだと思っていて、そのパッケージ構成ってみんなどうしているのかな？と悩んで調べてみると、以前、DDDの勉強に参考にさせていただいたかとじゅん(@j5ik2o)さんのブログが参考になりそう。

Scalaコードでわかった気になるDDD | GREE Engineering

ドメインモデルはユビキタス言語でグルーピングする

net.gree.xxx.domain.hunter  
 Hunter, HunterName, HunterRank

net.gree.xxx.domain.monster
 Monster

net.gree.xxx.domain.item
 Item, ItemService

MVC の Model 肥大化への対処 #初心者 - Qiita

実装サンプルのフォルダ構成よりも、こちらの方がしっくりする。RepositoryやEntityとの兼ね合いに悩みが生まれそうだけど、それは今後、自分で実装する中で考え直そうということで保留。

DAO

インピーダンス・ミスマッチを解決する、O/Rマッピングの設計

逆に考えてたけど、確かにこちらの方が良いかも。
今度(いつ？)試してみよう https://t.co/hziCFJUBml
— Yamashita (@_vermeer_) 2020年4月13日

Form

Railsアプリケーションでフォームをオブジェクトにして育てる - クックパッド開発者ブログ

decorator, presenter, exhibit という3つの実装パターンについて - pospomeのプログラミング日記

クラス

同じようなPOJOだけど色々分類がされていて、その違いを考えるのに参考になる。

【JavaBeans】BeanとDTOとEntityとVOとFormの違いって何？ - プログラマのはしくれダイアリー

モデリング

http://blog.amateur-factory.jp/?eid=1444289

さくさく要件定義セミナー in 大阪 from Zenji Kanzaki

www.slideshare.net

2018/3/22 追記

モデリング：９つの誤解 by S. Ambler
1. モデル＝ドキュメント
2. 最初からすべてが見通せる
3. モデリングは重いプロセス
4. 要求は凍結できる
5. 設計は不変
6. モデリングとはツールを使うこと
7. モデリングは時間のムダ
8. データモデリングが開発の中心
9. モデリングスキルなしに開発できる
— 増田亨． (@masuda220) 2018年3月22日