システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る

DDDのメモ

概念

原本のエッセンス

[ 技術講座 ] Domain-Driven Designのエッセンス 第1回|オブジェクトの広場

[ 技術講座 ] Domain-Driven Designのエッセンス 第2回|オブジェクトの広場

[ 技術講座 ] Domain-Driven Designのエッセンス 第3回|オブジェクトの広場


IDDD本から理解するドメイン駆動設計連載一覧:CodeZine(コードジン)


DDD超入門(前編) - Domain-Driven Designの概要 - エンタープライズギークス (Enterprise Geeks)

DDD超入門(後編) - Domain-Driven Designの適用Step - エンタープライズギークス (Enterprise Geeks)

全般的

ドメイン駆動設計の定義についてEric Evansはなんと言っているのか[DDD] - little hands' lab

境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab

DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - little hands' lab

speakerdeck.com

ドメイン駆動設計+クリーンアーキテクチャ解説【DDD編】

ドメイン駆動設計+クリーンアーキテクチャ解説【クリーンアーキテクチャ編】

https://tagoto.atlassian.net/wiki/spaces/public/blog/2018/02/18/37061127/DDD+Hexagonal+Onion+Clean+CQRS

ボトムアップドメイン駆動設計 │ nrslib

ユースケース

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

CQRS

www.slideshare.net

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

www.slideshare.net

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

書籍

vermeer.hatenablog.jp

関連資料

www.slideshare.net

www.slideshare.net

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

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

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

いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - yvsu pron. yas

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


実装

DDD の Java EE 実装サンプル - Cargo Tracker を読み解く

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

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

ドメインモデルをコードへ落とす 〜あなたのクラスは、どこから?〜

構成

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

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

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

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

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

net.gree.xxx.domain.monster
 Monster

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

MVC の Model 肥大化への対処

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

DAO

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

Form

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

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


クラス

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

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


モデリング

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

www.slideshare.net


  • 2018/3/22 追記

私なりに、読み替えてみました。

  1. モデルはドキュメントではない
    ドキュメントのためのドキュメントではなく実現する手段であるってこと、かな?

  2. 最初からすべては見通せない
    徐々に組み立てていくもの

  3. モデリングは軽快なプロセスであるべき

  4. 要求は変化する
    要求には柔軟に対応する

  5. 設計も変化する
    設計も柔軟に変化する

  6. ツールを使うことがモデリングではない。
    手段は目的ではない。
    例えば、UMLで記述すればモデリングしたことになわけではない。

  7. モデリングは重要不可欠

  8. ドメインモデルを開発の中心に。

  9. 開発にはモデリングスキルが必要