【DDD】ドメイン駆動設計【エリック・エヴァンス】

**デフォルトの名無しさん** · 2017/10/24(火) 19:39:06.49

第1部　ドメインモデルを機能させる

　　　ドメイン駆動設計におけるモデルの有用性
　　　ソフトウェアの核心

第1章知識をかみ砕く
　　　効果的なモデリングの要素
　　　知識のかみ砕き
　　　継続的学習
　　　知識豊富な設計
　　　　　　例1.1——隠された概念を引き出す
　　　深いモデル

第2章コミュニケーションと言語の使い方
　　　ユビキタス言語（UBIQUITOUS LANGUAGE）
　　　　　　例2.1——貨物輸送プログラムを完成させる
　　　声に出してモデリングする
　　　1つのチームに1つの言語
　　　ドキュメントと図
　　　　　　書かれた設計ドキュメント
　　　　　　実行可能な基盤
　　　説明のためのモデル
　　　　　　例2.2——輸送業務と経路

第3章モデルと実装を結びつける
　　　モデル駆動設計（MODEL-DRIVEN DESIGN）
　　　モデリングパラダイムとツールによるサポート
　　　　　　例3.1——手続き型からモデル駆動へ
　　　骨格を見せる：なぜモデルがユーザにとって重要なのか？
　　　実践的モデラ（HANDS ON MODELERS）

**デフォルトの名無しさん** · 2017/11/05(日) 15:16:50.90

>>70
移植先のフレームワークも似たような機能が揃ってるから大した手間にならん
フレームワークに沿って高生産の仕事を2回やるだけ
しかもフレームワークは似てるので2回目はさらに簡単

生産性をあげるのがフレームワークだ
それに逆らってDDDをやっても生産性を下げるだけ
移植するときにもまた他のフレームワークに逆らうことになり生産性を下げざるをえない
苦痛を2回も強いられる

**デフォルトの名無しさん** · 2017/11/05(日) 15:33:43.90

まず、DDDはフレームワークに逆らっている、というのがよくわからん
具体的にはどういうこと？

**デフォルトの名無しさん** · 2017/11/05(日) 15:38:24.62

>>72
フレームワークを使った開発ではプレーンなオブジェクトに属性を付けて不変条件を守るスタイルが優勢

DDDは余計なメンバを公開しないしインフラから切り離すので属性にも依存したくない
フレームワークの利点を潰してしまう

**デフォルトの名無しさん** · 2017/11/05(日) 15:58:00.31

具体的なフレームワーク名も挙げずに何言ってんのこいつ

**デフォルトの名無しさん** · 2017/11/05(日) 16:00:49.98

>>74
最近のフレームワークはどれも同じようなものって言ってるだろ
なら具体的にあげる意味はないね

**デフォルトの名無しさん** · 2017/11/05(日) 16:04:04.40

>>75
知らないだけ

**デフォルトの名無しさん** · 2017/11/05(日) 16:04:32.12

>>75
具体例を

**デフォルトの名無しさん** · 2017/11/05(日) 19:48:21.92

サービス層とMVCのコントローラは何が違うのか
情弱の俺に教えてくれよ。

**デフォルトの名無しさん** · 2017/11/05(日) 20:15:07.05

>>68
最初から予定してる場合は？

**デフォルトの名無しさん** · 2017/11/05(日) 20:21:57.83

>>78
サービスって言葉は色んな意味で使われるから分かりにくい
特定のクラスに属するとマズイ処理を実装するところだと理解してるけど

MVCのCはそのまんまUIとモデルの橋渡しでしょ

**デフォルトの名無しさん** · 2017/11/05(日) 20:29:14.50

ドメインモデルっていうくらいなんだから
サービスドメインはモデルでしょうな

**デフォルトの名無しさん** · 2017/11/05(日) 21:16:49.89

>>63
その割にはドメインに対する理解とかには全然注力しない印象。
業務系だったら、簿記や会計の勉強したりとか。

**デフォルトの名無しさん** · 2017/11/05(日) 21:20:40.35

>>67
＞OO系のスレってアンチが粘着しがち
OOが難しいから否定したいんだろう
関数型のスレにもいるだろ

**デフォルトの名無しさん** · 2017/11/05(日) 22:13:53.69

>>78
似てるけど微妙に違う

Mにドメイン層とインフラ層が一緒になってるのは分かるよな
サービス（アプリ）層はCとMの一部が一緒になってる

**デフォルトの名無しさん** · 2017/11/06(月) 00:29:31.84

ここは軽量DDDを議論するところなの？

**デフォルトの名無しさん** · 2017/11/06(月) 13:22:13.87

>>84
リクエストとレスポンスのインタラクションは
コントローラ
データの「加工」「変換」「検索」「演算」「結合」
ここらへんが絡む物はサービス?
DBMSのコネクションの利用はモデルじゃなくてサービスかな
モデルはただ単に「属性」を持っているだけでいい。
それと最低限のゲッターとセッター
こんなところだろうか？？
バリデーションや業務ルールのチェックはモデル？？サービス？？

**デフォルトの名無しさん** · 2017/11/06(月) 19:18:41.19

考えるな　感じるんだ

じゃなくて
周りに合わせるんだ
どんなくそ設計でも検証通ったコードと一貫性が保たれてるほうが品質高い

サービスだとおもいます

**デフォルトの名無しさん** · 2017/11/10(金) 15:55:49.97

他人が構築したドメイン構造を把握するスキルも
重要なのかな?
日本のSIlerの場合常駐先がしょっちゅう変わったりする
んだからそうなるとドメインを構築しようとか
どんなドメインなのかの把握が面倒になってしまう。

**デフォルトの名無しさん** · 2017/11/10(金) 21:17:00.97

>>86
いろんな考え方があるけど一番シンプルなのは
DDDではドメインが一番大事だからドメインと他を切り分けること

UIとDBは明らかに分かると思うからそれをどけて
残るのはアプリ（サービス）層とドメイン層の区別

両者は混同されやすくサービスの肥大化がよく起こるので
リファクタリングを続けて継続的に
ドメインの知識はドメイン層へと移動させていく

＞バリデーションや業務ルールのチェック
たしかにこれはどっちに置くか難しいけど
私ならドメインの知識になってるかどうかで考える

たとえばよくある例では日付でうるう年の判定などは
明らかにドメインの知識だからドメイン層に置く

**デフォルトの名無しさん** · 2017/11/12(日) 10:23:37.61

バリデーションはエラーメッセージ、UIの強調表示なども絡むからどう考えたってプレゼンテーション層でしょ
ビューモデル(プレゼンテーションの都合であるモノ)のプロパティ属性にバリデーションルールを書くことが標準的になっている点からもこの事実は明らか

**デフォルトの名無しさん** · 2017/11/13(月) 07:29:43.51

>>90
ASP.NETだけどビューにバリデーション書いたとしてjavascriptゴニョゴニョされてバリデーション突破されたら怖いからコントローラにもチェック入れてる
設計的に正しいのかは解らない

**デフォルトの名無しさん** · 2017/11/13(月) 08:20:06.77

>>91
>>90とやってること一緒じゃね？

**デフォルトの名無しさん** · 2017/11/13(月) 08:41:32.54

目的が違えば両方あってもいいんじゃね？ユーザーの利便のためか自衛のためか。

**デフォルトの名無しさん** · 2017/11/13(月) 09:17:00.78

>>91
ASP.NETって、ビューモデルのバリデーションをクライアント側のJSで突破できちゃうの？

**デフォルトの名無しさん** · 2017/11/13(月) 12:08:35.87

ジャバオのバリデータだろ

**デフォルトの名無しさん** · 2017/11/13(月) 18:48:33.23

>>94
そう書いたらそうなる
普通はControllerでチェックする

**デフォルトの名無しさん** · 2017/11/13(月) 20:17:19.09

>>90
クライアントのJSで検証したらサーバー側のコントローラで検証しなくても良いと？
んなわけねーだろ普通両方やるわ

**デフォルトの名無しさん** · 2017/11/13(月) 22:06:30.64

プレゼンテーション層でチェック
クライアントでチェックする

一緒にしてる奴がいるね
ちなみにコントローラーもプレゼンテーション層な

**デフォルトの名無しさん** · 2017/11/14(火) 05:47:03.90

>>98
>>97は
https://blogs.msdn.microsoft.com/nakama/2009/09/28/293/
で触れてるような信頼境界の話だろ

**デフォルトの名無しさん** · 2017/11/14(火) 07:18:29.77

>>98
Controlerってアプリケーション層じゃ無いんだ
出典無いから自信無いけど

**デフォルトの名無しさん** · 2017/11/14(火) 19:38:43.49

セキュリティとか悪意のある攻撃を想定すると
話が厄介になるね
セキュリティ考慮でなければ、情報の源泉に近い
JSでバリデーション1本だけで十分だろう。
セキュリティとか認証が絡むとこういったレイヤの層分け
が狂う要因になるのだろうか？

**デフォルトの名無しさん** · 2017/11/15(水) 03:47:42.79

>>101
仕事で使うなら想定しないケースも希だと思うけど

**デフォルトの名無しさん** · 2017/11/16(木) 07:24:52.29

DIのフレームワークとDDDって共存できるの

DDDってMVCみたいなレイヤードアーキテクチャからドメイン抜き出したもの程度しか認識ない人間だけど

**デフォルトの名無しさん** · 2017/11/16(木) 07:30:52.62

>>103
MVCはレイヤードアーキテクチャじゃないよ

**デフォルトの名無しさん** · 2017/11/16(木) 12:33:04.40

>>104
モデルビューコントローラはレイヤじゃ無いのか
そう言えばモデル層とか聞かないね

**デフォルトの名無しさん** · 2017/11/17(金) 08:39:38.18

validationとormがDDDのボトルネック
要するに机上の空論

**デフォルトの名無しさん** · 2017/11/17(金) 23:50:35.86

UIの要求が強すぎるとうまくいかんのだわ
ドメインクラスをフロントとバックの両方に書くはめになる
Node.jsだとそのへんうまくいくのかな

**デフォルトの名無しさん** · 2017/11/18(土) 13:44:21.91

お前ら設計書ってどうしてる？
仕事でやる以上は設計書出せと言われたら書かなきゃならない
設計書がレビュー通らなきゃコーディングは始められない
バリューオブジェクトの設計書とかあまりにも馬鹿馬鹿しいんだけど何百個も書かなければならない

**デフォルトの名無しさん** · 2017/11/18(土) 15:21:12.87

>>108
なんて言ってほしいのかわからない
仕事なんだからやれって言われたらヤるしないって立場なんでしょ？
じゃあやるしかないじゃん

バリューオブジェクト数百個っていったらそれなりの規模のシステムだろうから
バリューオブジェクトを使わなかったとしてもどうせ大量の設計書を書かないといけないし、
今となってはそういう仕事を受けたのを悔やむことぐらいしかできないのでは？

**デフォルトの名無しさん** · 2017/11/18(土) 15:39:25.13

しかも設計書がExcel方眼紙なんだよな。

**デフォルトの名無しさん** · 2017/11/18(土) 15:47:54.83

設計書なんで実装終わったときに揃ってれば良いだろ
どうせ開発中にコロコロ仕様変わるなんてよくある話だ

**デフォルトの名無しさん** · 2017/11/18(土) 16:01:31.09

レビューがあるから先に設計書を書かないとダメ
でも設計書で設計するとグダグダになる
設計書から目をそらす以外にうまくいく方法があるなら教えてくれ

**デフォルトの名無しさん** · 2017/11/19(日) 08:43:56.41

テキトーに書いておく
レビューする側に解ってる人がいるのは稀だからタイテーはこれで何とかなる

**デフォルトの名無しさん** · 2017/11/19(日) 11:30:11.10

先にユニットテスト済みのコードを書く
doxygenで設計書生成
レビューしてOKを貰う
コーディングしてるふりして1日サボる
コードをプッシュ

**デフォルトの名無しさん** · 2017/11/19(日) 12:43:48.77

>>114
doxygenってExcel方眼紙出せたっけ?

**デフォルトの名無しさん** · 2017/11/19(日) 13:09:42.41

エクセル設計書なんて使わない

**デフォルトの名無しさん** · 2017/11/19(日) 13:56:40.03

>>116
使いたかないけどさ。
たぶん >>108 にそんな自由はない。

**デフォルトの名無しさん** · 2017/11/19(日) 16:15:48.08

Excelに貼り付けるテキストを自作ツールで出力。

**デフォルトの名無しさん** · 2017/11/22(水) 15:13:08.97

ビジネスロジック層と永続化層の違いについて聞きたいんだが
「ビジネスロジック」は「犬」とか「リンゴ」とかいうクラスを作る層で
「永続化層」は「犬テーブルを操作するオブジェクト」を定義するクラス
を作る（というかPDOとかActive Recordとかが用意している)という
認識でいいのか?

**デフォルトの名無しさん** · 2017/11/22(水) 18:17:46.26

ざっくり言うとデータベースに関係あるのがインフラ層

**デフォルトの名無しさん** · 2017/12/05(火) 00:47:41.31

エヴァとのコラボカードナナコ最高。http://maeda-gourmet.jp/2016/09/09/nanaco/

**デフォルトの名無しさん** · 2018/05/23(水) 21:07:55.14

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

Q3XKO

**デフォルトの名無しさん** · 2018/07/05(木) 00:49:06.04

ZJY

**デフォルトの名無しさん** · 2018/09/09(日) 06:43:58.22

ゲーム開発でDDDは使えますか？
その場合のドメインとドメインエキスパートとは例えば何、誰を指すでしょうか？

**デフォルトの名無しさん** · 2018/10/08(月) 00:49:59.53

ボトムアップドメイン駆動設計
https://ddd-community-jp.connpass.com/event/103428/

ぜひ参加してください！

**デフォルトの名無しさん** · 2018/10/11(木) 20:53:29.46

Eric Evans氏はドメイン駆動設計(DDD) は未完成だと述べた
https://www.infoq.com/jp/news/2018/10/ddd-not-done

**デフォルトの名無しさん** · 2018/10/24(水) 09:23:12.56

>>125
講師がひとりで勝手に盛り上がってて寒いセミナーだったな
マーケ視点で物事を考えない典型的駄目エンジニアって感じだから内容も薄い薄い

**デフォルトの名無しさん** · 2018/10/25(木) 01:29:02.78

こんなやつらがDDDやってるんだなってのがわかって結構面白かったけどね
今日の内容で本書きます！って言われたときはさすがに周り失笑してたけど

**デフォルトの名無しさん** · 2019/03/17(日) 12:58:39.06

まだ、軽量DDDなんかやっている人がいるのね。

**デフォルトの名無しさん** · 2019/04/25(木) 08:19:51.47

意外と盛り上がらないね。

**デフォルトの名無しさん** · 2019/04/25(木) 20:00:13.26

ドメインが複雑じゃないとあんまり意味なさそうなのは感じ無くもないけど、将来の改修のしやすさのための布石と思えばいいのかな。

**デフォルトの名無しさん** · 2019/05/06(月) 12:07:22.28

>>131
　ドメインモデルが有効に機能するのって、イラレ、フォトショ、動画編集、オフィス系のようなパッケージアプリぐらいだと思う。

　普通のDB叩くアプリではいらないと思う。

**デフォルトの名無しさん** · 2019/06/20(木) 07:02:35.15

業務系はエンティティ間の関連が多すぎてリポジトリパターンと相性が悪いと思う
トランザクション分析すると集約ルートが複数のテーブル全体を巻き込んだりする

**デフォルトの名無しさん** · 2019/10/11(金) 20:14:12.01

最近DDDの本読んで勉強してるが、日本じゃ流行らなさそうだなという印象
英語圏なら確かにユビキタス言語からコードにシームレスに移れ、
コードがそのままドメインエキスパートにも読めるドキュメントにできるだろうが…

**デフォルトの名無しさん** · 2019/10/12(土) 06:32:18.26

古典的なデータモデリングのマッピング先がOOPに変わっただけという印象なんだけど。

**デフォルトの名無しさん** · 2019/10/12(土) 14:21:09.70

>>135
DDD本で紹介されてる概念やテクニックはOOPに限られたものじゃないよ
DOAの古典的データモデリングでも十分に役立つし関数型のパラダイムで実装することもできる

日本語でDDDについて書かれてる記事は質が低いのが多いから
ちゃんと理解したければEric Evansの原典かVernonの"Domain-Driven Design Distilled"を読むのを勧める

**デフォルトの名無しさん** · 2019/11/27(水) 21:15:02.91

「Hands-On Domain-Driven Design with .NET Core」Alexey Zimarev

これ結構いい本
Packtのサイトでセール中なのか今なら10$で買える

**デフォルトの名無しさん** · 2019/12/22(日) 03:38:09.90

>> 128
これ？
https://www.shoeisha.co.jp/book/detail/9784798150727
目次見るとなんだかなと思う。

**デフォルトの名無しさん** · 2020/02/08(土) 08:56:40.52

モデル層とデータストア層って分離できないのかな。

仕様変更のしやすさからモデル層の独立を図る必要があるけど、
データベースファースト（テーブルが先にあってDBの都合で正規化済み）の場合、
どうやってモデル層とデータストア層を分離できるんだろう。

O/Rマッピングも使えない。
どうやって解決するのが一般的なんだろう。

そもそも、O/Rマッピングが完全にできたとしても、それは初期状態においてであって、
変更を重ねてモデルのフィールドが変更になれば、データテーブルも変更しなければならないはず。
理想ばかりでインピーダンス不整合が脳内で続くんだけど。

考えてばかりでプログラミングを開始できない。。。

**デフォルトの名無しさん** · 2020/02/08(土) 09:03:45.09

pythonでもドメイン駆動設計するのに問題ない？

**140** · 2020/02/08(土) 09:04:48.14

>>140
PythonのDjangoでWEBアプリを考えています。

**デフォルトの名無しさん** · 2020/02/08(土) 12:58:17.20

>>139
Django ORMはActive Record PatternだからDBが先にあるような場合にはうまくいかない
そもそもActive Record使ってるとモデルとデータストアの結合度が高い
分離したければRepository Patternを自分で実装するかそれをサポートしてるフレームワークを選択するか

“python repository pattern”で検索

**139** · 2020/02/09(日) 12:24:41.03

>>142
レスありがとうございました。

DjangoのActive Record Patternはコードファーストと呼ばれるやつですね。

モデルの変更がデータベーステーブルに直結するので、結合度が高いのがわかります。
最初の開発のしやすさがあっても、変更には弱いのだとわかりました。

python repository pattern について情報が少ないですね。

モデルとデータストアをどう分離できるか考えてみたいと思います。

モデルが何か中間層のオブジェクトを経由してデータテーブルに保存できるようにすれば、
モデルの変更はモデルの変更に終止させられるかもしれません。

**デフォルトの名無しさん** · 2020/02/09(日) 20:14:19.34

>>143
>モデルが何か中間層のオブジェクトを
それがリポジトリと呼ばれるもの

**デフォルトの名無しさん** · 2020/02/10(月) 00:10:18.78

>>144
なるほど。

あるモデルオブジェクトを、中間層にある一対一で対応したクラス食わせると、
データベースの正規化テーブルに適切に分配して、
保存してくれるようなイメージかなあと思っています。

それにしても、モデルの変更は中間層の対応クラスやデータテーブルにも及んでしまうなあ。

**デフォルトの名無しさん** · 2020/02/10(月) 20:33:59.96

モデルが中心で一番重要だから当たり前
データベースやフレームワークの都合でモデルが振り回される方が厄介

というか安定性が一番高く変化しにくいのがモデルのはずで、先にきちんと分析してある程度要件を固めないといけない

**デフォルトの名無しさん** · 2020/02/11(火) 10:44:43.50

>>146
モデル中心で設計していきたいと思います。

しかし、データベースが先に立っている旧システムのWEBアプリ化なので、
それらのテーブル上にまたがった（リレーションされた）データを、
どうモデルに切り分けると良いか考えたいと思います。

モデル(∞)-テーブル(1)のような関係になりそうです。
それを結合させられる中間層（リポジトリ？）を自分で考えたいと思います。

**デフォルトの名無しさん** · 2020/02/11(火) 12:30:25.83

リポジトリで重要なのはインターフェースと実装を分けること
インターフェースはモデル層になるけど、実装はモデル層にはなくデータベース関連の知識は実装に閉じ込める
python はインターフェースそのものはないみたいだから抽象基底クラスで代用したらどうか

# モデル層はインターフェースのみ定義する
# 使用するデータベースを変更するとか、テストするときはモックに差し替えるとかしやすくなる
from abc import ABC, abstractmethod

class Users(ABC):
　　@abstractmethod
　　def save(self, user: User) -> None:
　　　　pass

# 実装(インフラストラクチャ層)はお好きなデータベースやフレームワークのORMなどで
import sqlite3

class sqlite3Users(Users):
　　def __init__(self, conn: sqlite3.Connection):
　　　　self.conn = conn

　　def save(self, user: User) -> None:
　　　　# ...

**デフォルトの名無しさん** · 2020/02/11(火) 13:38:06.66

>>147
>テーブル上にまたがった（リレーションされた）データを、
>どうモデルに切り分けると良いか考えたいと思います。

それはモデル中心じゃなく既存テーブル中心設計じゃないか？

**デフォルトの名無しさん** · 2020/02/11(火) 19:36:41.89

とはいえ普通の開発は既存のDBのテーブルに引きづられるのが実際だろ。

**デフォルトの名無しさん** · 2020/02/11(火) 21:46:53.70

>>150
DDDのようなモデル中心の設計では
ビジネス要求だったりユースケースだったり
アプリケーションの外部仕様を満たすために最適なドメインモデル考えるのが先

既存DB構造を含めてそのモデルをどう永続化するかはそれよりも後
もちろん既存DBの構造によってドメインモデルを変更せざるを得ない場合もあるが
>>147が書いてるとは考え方の主従が違う

**デフォルトの名無しさん** · 2020/02/13(木) 00:19:28.03

GoとかRustとかのクラスベースじゃないのとJavaとかのクラスベースってどっちがDDDしやすいの？
ライブラリ、フレームワークとかの資産とかなしにして

**デフォルトの名無しさん** · 2020/02/13(木) 02:16:39.59

>>148
詳細なレスありがとうございます。

リポジトリの作成について、
インターフェイスと実装を分ける点についてしっかりと考えてみたいと思いました。

なるほど。
インターフェイスをモデルと合わせておくことは重要だと思いました。
少なくとも、データベース層の変更があってもインターフェイスの実装クラスまでで
影響をストップできるのは素晴らしいです。精神的に安心。
ドミノのストッパーみたいな感じがします。

Pythonにはインターフェイスの概念がないというお話を聞いて、
やはりC#（.net core）で構築することを考えました。
こちらは少し経験があるのでやりやすいからです。

本当はOSS界のPythonに憧れてはいたんですけどね。

**デフォルトの名無しさん** · 2020/02/13(木) 02:20:34.42

>>149-151
たしかに、
自分が求めに応じて何を作りたいのかが先に立ちますよね。
すると、モデルが先に来る。

しかし、既に構築済みシステムのデータベーステーブルの存在もあるので、
あくまで、モデル中心にして必要なデータを既存テーブルから拾ってくるというような考え方にしておきます。
その意味では、既存データベースに無い物はモデルとして成立させられないわけですが。

**デフォルトの名無しさん** · 2020/02/13(木) 15:23:21.01

53 恋する名無しさん
2018/12/15(土) 21:15:59.13 ID:Ai0sRA6M0

人様の家に放火する虫ケラ小宇根信博俊興マンコ顔ヤクザが偉そうなカオして長田高校におるわ
信博の眼球にアイスピック突き刺す
ゲロ小宇根
兵庫県教育委員会兵庫県立長田高校小宇根化学痴漢殺人放火魔仮面教師俊興信博エタ部落未逮捕、
兵庫県警ブラックリスト長田高校殺人教師小宇根信博放火殺人化学教師息子俊興二重人格兵庫県教育委員会小宇根信博長田高校の便所で毎日

うんこブリブリ親父家で俊興に便所占領されてカムリ白車で毎朝長田高校まで朝のウンコしに行く汚な顔仮面視強姦エロアニメ大量購入下三条町2-9

小宇根痴漢変態仮面ムッツリスケベブス汚な顔面放火焼け爛れゴキブリ顔信博殺人犯未逮捕女子高生レイプマニア怖い俊興ストーカー信博化学教師

兵庫県教育委員会長田高校長の家火葬場小宇根放火ストーカー魔に焼殺人された哀れ性暴力反社会人格障害教師にタンマリ給料やりステーキ食べ

させ放題放火すき焼き食べさせ放題兵庫県教育委員会長田高校長宅残虐家族全員焼け爛れ顔の長田高校長の家族全員焼死体無惨な長田高校全焼

兵庫県教育委員会は小宇根放火ストーカーに燃やされ全焼兵庫県教育委員会全員火の海俊興ストーカーに燃やされ小宇根放火焼殺魔精神異常家系

**デフォルトの名無しさん** · 2020/02/13(木) 18:03:52.96

>>152
クラスベースかどうかの違いはあまり関係ないんじゃないかな
ドメインモデルをコードに落としやすいかどうかは型の表現力によると思う

Sum Typeを作りやすいかどうかや
value object用のimmutableオブジェクトを作りやすいかどうかみたいな部分
RustやSwiftのenumだったりKotlinのdata classみたいなやつ

**デフォルトの名無しさん** · 2020/02/16(日) 13:43:23.03

ドメインモデル的にDBは検索可能なファイルフォーマットみたいな考え。
PDFやPSDファイルを考えるとわかりやすい。ファイルから読み出すとドメインモデルになる。

**デフォルトの名無しさん** · 2020/02/18(火) 21:40:17.43

それだとormはどういう位置付けになるん？

**デフォルトの名無しさん** · 2020/02/19(水) 00:06:44.71

>>158
Repositoryじゃね？

**デフォルトの名無しさん** · 2020/02/19(水) 00:14:21.11

性能で行き詰まった時に普通に破綻しそうなんだが。

**デフォルトの名無しさん** · 2020/02/19(水) 01:31:27.23

性能で行き詰まったら、金の弾丸ブチ込めってばっちゃが言ってた

**デフォルトの名無しさん** · 2020/02/20(木) 22:05:54.44

未だにファクトリーだけメリットがわかりません
newとなにが違うんですか？

**デフォルトの名無しさん** · 2020/02/20(木) 23:00:47.67

>>162
引数によって継承したクラスを選択して返す様に設計できる。

**デフォルトの名無しさん** · 2020/03/05(木) 22:14:17.50

>>152
オブジェクト指向言語の方が
DDDに基本的に向いていると思う

OO以外でももちろん可能だけど
ドメインの表現はOOが一番やりやすい

JavaやC#
RubyやPythonも

**デフォルトの名無しさん** · 2020/03/05(木) 22:20:29.48

>>162
DDDというかデザインパターンの話だけど
ファクトリ（系パターン）を使うのは
インスタンスの生成が複雑な時

たとえばAとBのインスタンスを常にペアで使いたいとか
いろんな条件でnewする部分が肥大化していくようなら
毎回書くよりファクトリパターン使う方がスマートでしょ？

**デフォルトの名無しさん** · 2020/03/08(日) 23:30:12.89

そうかなあ…一番DDDやりやすいのは関数型言語だと思う

ドメイン設計って、
•あるデータはどんなデータがANDないしORで組み合わさって出来てるのか
•業務プロセスはそれらのデータをどのように変換していくのか
の2点が主だと思ってるけど、
これらは代数的データ型とパターンマッチによってダイレクトに表現できて、
業務プロセスは関数の連続で簡潔に表現できる。

また純粋なビジネスロジックは作用のない関数によって表現され、
ビジネスロジック以外の部分が作用を持つ関数になるはずで、
作用のある無しを型レベルで区別する純粋関数型言語であれば、
その辺の層分けもすごく自然　むしろ別れざるをえない

**デフォルトの名無しさん** · 2020/03/08(日) 23:55:07.82

作用？

**デフォルトの名無しさん** · 2020/03/09(月) 21:19:31.81

左様でござる

**デフォルトの名無しさん** · 2020/03/09(月) 22:12:07.02

Webみたいにステートレスで済むなら
関数型の方が簡潔に書ける部分もあるが

ビジネスロジックは複雑な状態遷移や
階層構造を持っていることが多いので

FPでもDDDはできるが
OOの方が向くことが多い

**デフォルトの名無しさん** · 2020/03/09(月) 22:18:06.74

階層構造を持ってるからOOの方が向いてるってのはよくわからないな

**デフォルトの名無しさん** · 2020/03/09(月) 23:12:50.10

？複雑な状態遷移があるとFPが向かないっていうのもよくわからないな
状態の数だけ型作って、遷移の数だけ関数つくればいいだけやん

OOPはむやみにクラス内に隠れた状態や依存を作って他のクラスとうまく合成されない物を作りがち
そんなことしてると、非同期な処理を並列化とかしようにも気にしないといけないことが増えて大変な労力だろうに