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

Javaで主にシステム開発をしながら思うところをツラツラを綴る。主に自分向けのメモ。EE関連の情報が少なく自分自身がそういう情報があったら良いなぁということで他の人の参考になれば幸い

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編】 - Qiita

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

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

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

https://www.slideshare.net/MasanobuNaruse/bottomup-ddd-1www.slideshare.net

https://www.slideshare.net/MasanobuNaruse/bottomup-ddd-2www.slideshare.net

www.slideshare.net

speakerdeck.com

speakerdeck.com

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

speakerdeck.com

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

speakerdeck.com

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

ユースケース

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

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

CQRS

www.slideshare.net

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

www.slideshare.net

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

Event

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

speakerdeck.com

www.youtube.com

書籍

vermeer.hatenablog.jp

www.slideshare.net

www.slideshare.net

www.slideshare.net

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

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

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

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

いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - higayasuo’s blog

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


実装

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

ドメイン駆動設計: IDDDに登場するサンプルコードのModule構成をまとめてみた - 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

実装サンプルのフォルダ構成よりも、こちらの方がしっくりする。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. 開発にはモデリングスキルが必要


その他(類似・未分類)

speakerdeck.com

www.slideshare.net

オブジェクト指向が難しく、わからないときの勉強方法【分かりやすく学習を進めるコツ】 - コーギーブログ