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

1 ：デフォルトの名無しさん：2017/10/24(火) 19:39:06.49 ID:jO+jDbIG.net

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

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

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

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

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

2 ：デフォルトの名無しさん：2017/10/24(火) 19:40:39.31 ID:vrotHuwu.net

>>1
いきなり目次って
ここ読書スレ？

3 ：デフォルトの名無しさん：2017/10/24(火) 19:40:53.73 ID:jO+jDbIG.net

第2部　モデル駆動設計の構成要素

第4章 ドメインを隔離する
　　　レイヤ化アーキテクチャ（LAYERED ARCHITECTURE）
　　　　　　例4.1——オンラインバンキングの機能をレイヤに分割する
　　　　　　レイヤを関係づける
　　　　　　アーキテクチャフレームワーク
　　　ドメイン層はモデルが息づく場所
　　　利口なUI「アンチパターン」（SMART UI ﾒANTI-PATTERNﾓ）
　　　その他の隔離

4 ：デフォルトの名無しさん：2017/10/24(火) 19:41:31.02 ID:jO+jDbIG.net

第5章 ソフトウェアで表現されたモデル
　　　関連
　　　　　　例5.1——証券取引口座における関連
　　　エンティティ（ENTITIES）（別名　参照オブジェクト（REFERENCE OBJECTS））
　　　　　　エンティティをモデル化する
　　　　　　同一性のための操作を設計する
　　　値オブジェクト（VALUE OBJECTS）
　　　　　　値オブジェクトを設計する
　　　　　　例5.2——値オブジェクトを使ってデータベースをチューニングする
　　　　　　値オブジェクトを含む関連を設計する
　　　サービス（SERVICES）
　　　　　　サービスと隔離されたドメイン層
　　　　　　粒度
　　　　　　サービスへのアクセス
　　　モジュール（MODULES）（別名　パッケージ（PACKAGES））
　　　　　　アジャイルモジュール
　　　　　　例5.3——Javaにおけるパッケージのコーディング規約
　　　　　　インフラストラクチャ駆動パッケージングの落とし穴
　　　モデリングパラダイム
　　　　　　なぜオブジェクトパラダイムが主流なのか？
　　　　　　オブジェクトの世界におけるオブジェクトではないもの
　　　　　　パラダイムを混在させる際にはモデル駆動設計に忠実であること

5 ：デフォルトの名無しさん：2017/10/24(火) 19:42:12.50 ID:jO+jDbIG.net

第6章 ドメインオブジェクトのライフサイクル
　　　集約（AGGREGATES）
　　　　　　例6.1——購入注文の整合性
　　　ファクトリ（FACTORIES）
　　　　　　ファクトリとその場所を選択する
　　　　　　コンストラクタがあればよい場合
　　　　　　インタフェースを設計する
　　　　　　不変条件のロジックはどこへ置くべきか？
　　　　　　エンティティファクトリ対値オブジェクトファクトリ
　　　　　　格納したオブジェクトを再構成する
　　　リポジトリ（REPOSITORIES）
　　　　　　リポジトリに対して問い合わせる
　　　　　　クライアントのコードはリポジトリの実装を無視するが、開発者はそうではない
　　　　　　リポジトリを実装する
　　　　　　フレームワークの範囲内で作業する
　　　　　　ファクトリとの関係
　　　関係データベースに合わせてオブジェクトを設計する

6 ：デフォルトの名無しさん：2017/10/24(火) 19:42:47.43 ID:jO+jDbIG.net

第7章 言語を使用する：応用例
　　　貨物輸送システムを導入する
　　　ドメインを隔離する：アプリケーションの導入
　　　エンティティと値オブジェクトを区別する
　　　　　　役割とその他の属性
　　　輸送ドメインの関連を設計する
　　　集約の境界
　　　リポジトリを選択する
　　　シナリオをウォークスルーする
　　　　　　サンプルアプリケーションの機能：貨物の荷出し地を変更する
　　　　　　サンプルアプリケーションの機能：リピータへの対応
　　　オブジェクトの生成
　　　　　　貨物用のファクトリとコンストラクタ
　　　　　　荷役イベントを追加する
　　　リファクタリングのために立ち止まる：貨物集約についてのもう1つの設計
　　　輸送モデルにおけるモジュール
　　　新機能を導入する：配分チェック
　　　　　　2つのシステムを接続する
　　　　　　モデルを強化する：ビジネスのセグメント化
　　　　　　パフォーマンスチューニング
　　　最後に

7 ：デフォルトの名無しさん：2017/10/24(火) 19:43:20.05 ID:jO+jDbIG.net

第3部　より深い洞察へ向かうリファクタリング

　　　リファクタリングのレベル
　　　深いモデル
　　　深いモデル／しなやかな設計
　　　発見のプロセス

第8章 ブレイクスルー
　　　ブレイクスルーの話
　　　　　　悪くないモデルなのだが…
　　　　　　ブレイクスルー
　　　　　　さらに深いモデル
　　　　　　冷静な意思決定
　　　　　　結末
　　　好機
　　　基本への集中
　　　エピローグ：新しい洞察の連鎖

8 ：デフォルトの名無しさん：2017/10/24(火) 19:43:49.53 ID:jO+jDbIG.net

第9章 暗黙的な概念を明示的にする
　　　概念を掘り出す
　　　　　　言葉に耳を傾ける
　　　　　　例9.1——輸送モデルに欠けている概念を聞き分ける
　　　　　　ぎこちなさを精査する
　　　　　　例9.2——利息を得る　難しい方法
　　　　　　矛盾について熟考する
　　　　　　文献を読む
　　　　　　例9.3——利息を得る　文献を用いた場合
　　　　　　何度でも挑戦すること
　　　それほど明白でない概念をモデル化する方法
　　　　　　明示的な制約
　　　　　　例9.4——再考：オーバーブッキングポリシー
　　　　　　ドメインオブジェクトとしてのプロセス
　　　仕様（SPECIFICATION）
　　　　　　仕様の適用と実装
　　　　　　例9.5——化学製品倉庫での格納
　　　　　　例9.6——倉庫内格納サービスの、実際に動作するプロトタイプ

9 ：デフォルトの名無しさん：2017/10/24(火) 19:44:14.81 ID:jO+jDbIG.net

第10章 しなやかな設計
　　　意図の明白なインタフェース（INTENTION-REVEALING INTERFACES）
　　　　　　例10.1——リファクタリング：塗料混合アプリケーション
　　　副作用のない関数（SIDE-EFFECT-FREE-FUNCTIONS）
　　　　　　例10.2——リファクタリング：塗料混合アプリケーション再考
　　　表明（ASSERTIONS）
　　　　　　例10.3——塗料の混合に戻る
　　　概念の輪郭（CONCEPTUAL CONTOURS）
　　　　　　例10.4——発生の輪郭
　　　独立したクラス（STANDALONE CLASSES）
　　　閉じた操作（CLOSURE OF OPERATIONS）
　　　　　　例10.5——コレクションから選択する
　　　宣言的な設計
　　　　　　ドメイン特化言語
　　　設計の宣言的スタイル
　　　　　　宣言的スタイルで仕様を拡張する
　　　　　　例10.6——コンポジット仕様を実装する他の方法
　　　攻める角度
　　　　　　サブドメインを切り取る
　　　　　　可能な場合には、確立された形式主義を活用する
　　　　　　例10.7——パターンを統合する：シェア算

10 ：デフォルトの名無しさん：2017/10/24(火) 19:44:34.64 ID:jO+jDbIG.net

第11章 アナリシスパターンを適用する
　　　　　　例11.1——利息を得る　勘定を用いた場合
　　　　　　例11.1（続き）——夜間バッチについての洞察
　　　　　　アナリシスパターンは活用すべき知識である

第12章 デザインパターンをモデルに関係づける
　　　ストラテジー（STRATEGY）（別名　ポリシー（POLICY））
　　　　　　例12.1——経路検索ポリシー
　　　コンポジット（COMPOSITE）
　　　　　　例12.2——経路で構成された輸送経路
　　　なぜ、フライウェイトではないのか？

第13章 より深い洞察へ向かうリファクタリング
　　　開始
　　　探究チーム
　　　先達の技
　　　開発者のための設計
　　　タイミング
　　　好機となる危機

11 ：デフォルトの名無しさん：2017/10/24(火) 19:45:17.29 ID:jO+jDbIG.net

第4部　戦略的設計

第14章 モデルの整合性を維持する
　　　境界づけられたコンテキスト（BOUNDED CONTEXT）
　　　　　　例14.1——予約コンテキスト
　　　　　　境界づけられたコンテキスト内での分派を認識する
　　　継続的な統合（CONTINUOUS INTEGRATION）
　　　コンテキストマップ（CONTEXT MAP）
　　　　　　例14.2——輸送アプリケーションにおける2つのコンテキスト
　　　　　　コンテキストの境界で行うテスト
　　　　　　コンテキストマップを構成してドキュメント化する
　　　境界づけられたコンテキスト間の関係
　　　共有カーネル（SHARED KARNEL）
　　　顧客／供給者の開発チーム（CUSTOMER/SUPPLIER DEVELOPMENT TEAMS）
　　　　　　例14.3——収益分析と予約
　　　順応者（CONFORMIST）
　　　腐敗防止層（ANTICORRUPTION LAYER）
　　　　　　腐敗防止層のインタフェースを設計する
　　　　　　腐敗防止層を実装する
　　　　　　例14.4——レガシー予約アプリケーション
　　　　　　訓話

12 ：デフォルトの名無しさん：2017/10/24(火) 19:45:38.94 ID:jO+jDbIG.net

　　　別々の道（SEPARATE WAYS）
　　　　　　例14.5——保険プロジェクトの縮小化
　　　公開ホストサービス（OPEN HOST SERVICE）
　　　公表された言語（PUBLISHED LANGUAGE）
　　　　　　例14.6——化学のための公表された言語
　　　象のモデルを統一する
　　　　　　モデルコンテキスト戦略を選択する
　　　　　　チームでの意思決定と、より上層での意思決定
　　　　　　コンテキストに自らの身を置く
　　　　　　境界を変換する
　　　　　　変更できないものを受け入れる：外部システムの輪郭を描く
　　　　　　外部システムとの関係
　　　　　　設計中のシステム
　　　　　　別のモデルで特殊な要求を満たす
　　　　　　デプロイ
　　　　　　トレードオフ
　　　　　　すでにプロジェクトが進行中の場合
　　　変換
　　　　　　コンテキストをマージする：別々の道 → 共有カーネル
　　　　　　コンテキストをマージする：共有カーネル → 継続的な統合
　　　　　　レガシーシステムを段階的に廃止する
　　　　　　公開ホストサービス → 公表された言語

13 ：デフォルトの名無しさん：2017/10/24(火) 19:46:02.22 ID:jO+jDbIG.net

第15章 蒸留
　　　コアドメイン（CORE DOMAIN）
　　　　　　コアを選択する
　　　　　　誰がこの作業をやるのか？
　　　蒸留の拡大
　　　汎用サブドメイン（GENERIC SUBDOMAINS）
　　　　　　例15.1——2つのタイムゾーンの物語
　　　　　　汎用とは再利用可能という意味ではない
　　　　　　プロジェクトのリスク管理
　　　ドメインビジョン声明文（DOMAIN VISION STATEMENT）
　　　強調されたコア（HIGHLIGHTED CORE）
　　　　　　蒸留ドキュメント
　　　　　　コアにフラグを立てる
　　　　　　プロセスツールとしての蒸留ドキュメント
　　　凝集されたメカニズム（COHESIVE MECHANISMS）
　　　　　　例15.2——組織図におけるメカニズム
　　　　　　汎用サブドメイン対凝集されたメカニズム
　　　　　　メカニズムがコアドメインの一部である場合
　　　　　　例15.3——一巡：組織図がメカニズムを再び吸収する
　　　蒸留して宣言的スタイルにする
　　　隔離されたコア（SEGREGATED CORE）
　　　　　　隔離されたコアを作成するコスト
　　　　　　チームの意思決定を進化させる
　　　　　　例15.4——貨物輸送モデルのコアを隔離する
　　　抽象化されたコア（ABSTRACT CORE）
　　　深いモデルの蒸留
　　　リファクタリングの対象を選ぶ

14 ：デフォルトの名無しさん：2017/10/24(火) 19:46:30.33 ID:jO+jDbIG.net

第16章 大規模な構造
　　　進化する秩序（EVOLVING ORDER）
　　　システムのメタファ（SYSTEM METAPHOR）
　　　　　　「素朴なメタファ」とそれを必要としない理由
　　　責務のレイヤ（RESPONSIBILITY LAYERS）
　　　　　　例16.1——深く掘り下げる：輸送システムをレイヤ化する
　　　　　　適切なレイヤを選択する
　　　知識レベル（KNOWLEDGE LEVEL）
　　　　　　例16.2——従業員の給料と年金（1）
　　　　　　例16.3——従業員の給料と年金（2）知識レベル
　　　着脱可能コンポーネントのフレームワーク（PLUGGABLE COMPONENT FRAMEWORK）
　　　　　　例16.4——SEMATECH CIMフレームワーク
　　　構造による制約をどの程度厳しくするべきか？
　　　ふさわしい構造へのリファクタリング
　　　　　　ミニマリズム
　　　　　　コミュニケーションと自己規律
　　　　　　再構成によってしなやかな設計がもたらされる
　　　　　　蒸留によって負荷が軽減される

15 ：デフォルトの名無しさん：2017/10/24(火) 19:46:47.01 ID:jO+jDbIG.net

第17章 戦略をまとめ上げる
　　　大規模な構造と境界づけられたコンテキストを組み合わせる
　　　大規模な構造と蒸留を組み合わせる
　　　まず評価する
　　　誰が戦略を策定するのか？
　　　　　　アプリケーション開発から現れる構造
　　　　　　顧客に焦点を合わせたアーキテクチャチーム
　　　戦略的設計上の意思決定を行うために欠かせない6つのこと
　　　　　　同じことが技術的なフレームワークにも当てはまる
　　　　　　マスタプランに注意すること

結論

　　　エピローグ
　　　展望

16 ：デフォルトの名無しさん：2017/10/25(水) 19:04:27.51 ID:44Xm0aVs.net

「境界づけられたコンテキスト」が
何のことかよくわからないので教えてください。

17 ：デフォルトの名無しさん：2017/10/25(水) 19:08:44.29 ID:aatZ8FSF.net

＞「境界づけられたコンテキスト」
ユビキタス言語の文脈が変わる境界のこと

たとえば「アカウント」は
金融なら口座だけど
Webサービスなら登録情報とか

18 ：デフォルトの名無しさん：2017/10/25(水) 19:31:11.15 ID:44Xm0aVs.net

>17
その境界はパッケージとかディレクトリとかで判断せよ
みたいな感じ?

19 ：デフォルトの名無しさん：2017/10/25(水) 19:49:21.67 ID:aatZ8FSF.net

>>18
DDDなら最初にまずドメインで判断すべき
どこまでが開発するドメインの範囲なのかって

Webサービスで通販やんないから
お金や口座は絡まないけど
ログインするタイプのサービスだとか

20 ：デフォルトの名無しさん：2017/10/25(水) 20:12:30.45 ID:44Xm0aVs.net

>>19
あーそうか、
Webサービスの場合、コンパイルしてバイナリ化しないから、
PHPの場合配備するAppはディレクトリ構造まんまになるんだけど、
システムの境界はどうやって判断するの？
設計図上でしか判断し得ないの？
サーバマシンの区切り? ディレクトリの区切り? URLのドメイン名の
区切り? その「DDDのあるドメイン」って実際のファイルシステム上では
どのように区切るの?

21 ：デフォルトの名無しさん：2017/10/25(水) 20:15:43.64 ID:aatZ8FSF.net

>>20
コンテキストの境界をシステムで表現する際には
（Javaなら）パッケージとその名前空間を使う

でもあくまでビジネスのドメインが先にあって
それにシステムを合わせるのであって
システムだけで判断したらダメだからね

22 ：デフォルトの名無しさん：2017/10/25(水) 21:51:00.68 ID:0GYD+24d.net

「境界づけられたコンテキスト」は組織構造やシステム構成でも変わりうるよ
特に組織構造への依存度は高いのでそれに応じたいくつかの戦略パターンが解説されてる

受注チームと出荷チームでは「商品」という言葉の意味が違ったり
レガシーシステムと新システムでは「商品」の属性やの振る舞いが違ったりするみたいなこと
一つの境界の中ではそういう違いは許されない

企業全体で統一された一つのモデルや用語集を作ろうとするのではなく
コンテキスト境界に閉じた中でモデルや語彙を明確にしようというのがDDDの考え方

23 ：デフォルトの名無しさん：2017/10/27(金) 20:24:53.95 ID:BY+fhh/f.net

実装とか物理設計の話になってすまないけど、
DBMSの「テーブルが所属するDB名の境界」が
上記の「境界づけられたコンテキストの」「境界」
に当たるのだろうか。

24 ：デフォルトの名無しさん：2017/10/27(金) 20:35:29.16 ID:NaPnvd1g.net

コンテキストとDBインスタンスを一致させてる

25 ：デフォルトの名無しさん：2017/10/28(土) 00:06:52.32 ID:EvuLUtue.net

>>23
一般的には当たらないことのほうが多いと思う
>>22の例で受注と出荷で違うコンテキストだったとしても
同じDBに属するテーブルを使うことはよくあるし
逆に複数のDBがひとつのコンテキストに属することもある

モデルやユビキタス言語のスコープが境界づけられたコンテキスト
境界は自然に決まるものじゃないから設計者がドメイン分析の過程で決めていくしかない

26 ：デフォルトの名無しさん：2017/10/29(日) 22:40:08.05 ID:CrDMqcML.net

ドメインて何ですか

27 ：デフォルトの名無しさん：2017/10/29(日) 22:58:36.50 ID:RyqL6Q1z.net

問題領域

28 ：デフォルトの名無しさん：2017/10/30(月) 12:05:58.95 ID:5RpC60IR.net

何が問題なんですか？

29 ：デフォルトの名無しさん：2017/10/30(月) 12:06:24.63 ID:5RpC60IR.net

トラブルエリアじゃ駄目なんですか？

30 ：デフォルトの名無しさん：2017/11/03(金) 08:47:57.76 ID:0WQ4WnED.net

大雑把に言うと、クラス名やメソッド名、変数名を使って仕事の会話を
しましょうと言うだけ。その逆も然り、それで違和感を感じたら設計や
用語を見直す。

31 ：デフォルトの名無しさん：2017/11/03(金) 08:53:45.98 ID:0WQ4WnED.net

バリューオブジェクトやエンティティとかリポジトリィとかは単なる設計/実装テクニック。

32 ：デフォルトの名無しさん：2017/11/03(金) 09:43:41.21 ID:Ro85MhDs.net

>>30
>クラス名やメソッド名、変数名を使って仕事の会話をしましょうと言うだけ。

根本的に間違ってるだろ

33 ：デフォルトの名無しさん：2017/11/03(金) 10:22:22.91 ID:wXWM393A.net

根本的な正解をヨロシク

34 ：デフォルトの名無しさん：2017/11/03(金) 10:33:38.13 ID:BtRYOGnT.net

俺も宜しく。

35 ：デフォルトの名無しさん：2017/11/03(金) 14:11:54.12 ID:CsNI9L5l.net

ビューモデル、データモデルとドメインモデルとの相互変換がめんどくさすぎる
バリューオブジェクトと集約ルートの考え方のせいで自動マッピング全然効かなくなるし

36 ：デフォルトの名無しさん：2017/11/04(土) 03:13:26.11 ID:b5UX6G3j.net

正直O/Rマッパーで取ってきたデータの入れ物をこねくり回す方が100倍楽なんだが、
大規模プロジェクトや長期のメンテが必要な場合以外でDDD使うケースってどれぐらいあるんだろ？

37 ：デフォルトの名無しさん：2017/11/04(土) 05:04:45.77 ID:7D9PjzRB.net

お前らががO/Rマッパーの中身を作ったことがあるならいいけど
そうじゃないと、その便利なO/Rマッパーに自分の技術者としての
存在価値を食い殺されることになるから気をつけろ。
DIY: 1度は作れ。最初から既存の便利なものは買うな、取り寄せるな。
DRY: 同じモノは2度も作るな。
つまり「自分の力で1度だけ作れ。」
0回もダメ, 2回以上同じモノを何度も作るのもダメ。

38 ：デフォルトの名無しさん：2017/11/04(土) 08:52:57.07 ID:/k8c/hp8.net

DDDってこんな感じじゃん？

画面: 集約ルートのメソッドのパラメータを入力させる
コントローラ: 入力をVOに変換してサービスに投げる
サービス: リポジトリから集約ルートとってくる & 集約ルートのメソッド呼び出す ; 集約ルートをリポジトリに保存する

でもユーザーが求めてるものってこれじゃないんだよね

画面: テーブル(データそのもの)を自由に編集 & 入力に間違いあれば警告 & 入力サポート処理
コントローラ: データ層に丸投げ
データ層: 受け取ったデータをそのまま保存する & 場合によりSQLでビジネスロジックを実行して結果を保存

ユーザーはこういうアプリケーションが大好き
とにかくひとつの画面に関連ありそうなものが全部見えて全部入力できないと気が済まない
集約ルートとか関係なしにぶら下がってるエンティティも直接編集したい
理想像はエクセルを機能拡張したようなもの
そのかわり入力に間違いがないようにバリデーションだけは異様にしっかりする

DDDはユーザーが求めてるものとは違うんだよ
エレガントなアプリを作りたいっていう開発者の都合でユーザーの求めているものとは全く異なるものを作ったら、優秀な技術者じゃなくて、ニーズが読めない二流って評価されちまう

MicrosoftもそれがわかってるからASP.NET MVCやEFのようなフレームワークを作った
ビューモデル、データモデルは振る舞いを持たない素朴なデータの集合の方がわかりやすいし楽だと割り切った
そして検証の工数を下げるために属性バリデーションが発達した
これは他の言語でもだいたい同じ
世界のトップレベルの開発者たちがDDDを否定して貧血ドメイン+強力な検証というパターンを選択した

39 ：デフォルトの名無しさん：2017/11/04(土) 09:24:40.15 ID:4lDAx3zT.net

今の仕事ドメインもどきの実装になってる

サービスは細かく区切ってあるけど
おのおの自分の担当データの整合性が保たれることだけを保証する

読み出しは自由

40 ：デフォルトの名無しさん：2017/11/04(土) 13:26:31.92 ID:O0AU1SEY.net

>>38
どこでどう勘違いしたらそんな理解になるの？

41 ：デフォルトの名無しさん：2017/11/04(土) 13:40:02.20 ID:/k8c/hp8.net

>>40
反論は最低限、論理的にお願いします

42 ：デフォルトの名無しさん：2017/11/04(土) 14:50:46.68 ID:7D9PjzRB.net

論理的推論（ろんりてきすいろん、英: logical reasoning）は、
論理学において演繹、帰納、アブダクション（仮説形成）の3種類に区別されうる。
「前提条件」（precondition）、「結論」（conclusion）、
そして「『前提条件』は『結論』を含意する」という
「規則」（rule）があるとすると、それら3種の推論は次の仕方で説明されうる。

演繹
演繹は「結論」を規定することを意味する。この推論は
「規則」と「前提条件」を用いて「結論」を導くことである。
例えば、「雨がふると芝生は湿る。雨がふっている。したがって、芝生は湿っている。
」数学者は通常、この種の推論にかかわっている。
帰納
帰納は「規則」を規定することを意味する。この推論は「前提条件」の次に起こる
「結論」の諸事例の一部から「規則」を学ぶことである。
例えば、「これまで、雨がふるといつも芝生は湿ってきた。
したがって、雨がふると芝生は湿る。」
科学者は通常、この種の推論にかかわっている。
アブダクション（仮説形成）
アブダクション（仮説形成）は過去事象についての「前提条件」
を推定することを意味する。この推論は現在確定される
「結論」と「規則」を用いて「ある『前提条件』が『結論』を
説明することができるだろう」ということを裏づけることである。
例えば、「芝生が湿っている。雨がふると芝生が湿る。
したがって、雨がふったに違いない。」
歴史科学者や診断専門医、探偵は通常、この種の推論にかかわっている。
https://ja.wikipedia.org/wiki/%E8%AB%96%E7%90%86%E7%9A%84%E6%8E%A8%E8%AB%96

43 ：デフォルトの名無しさん：2017/11/04(土) 18:46:52.01 ID:/k8c/hp8.net

反論はないということですね
やっぱりDDDはアンチパターンなんだ

44 ：デフォルトの名無しさん：2017/11/04(土) 19:11:47.69 ID:KxJ3WBAq.net

貧血ドメインごとに専用のサービスクラスを作るのはトランザクションスクリプト？

45 ：デフォルトの名無しさん：2017/11/04(土) 21:10:36.19 ID:Yu+eR6Tn.net

>>43
DDDの提唱者ですら言ってるよ
ビジネスロジックが複雑でないドメイン、例えばただのCRUDみたいに、
DBのUIでしかないようなアプリはDDDでやる意味ないって

46 ：デフォルトの名無しさん：2017/11/04(土) 21:21:57.79 ID:/k8c/hp8.net

>>45
その複雑なドメインってのがそもそも現実的じゃないんだよ
すべてのアプケーションはDDDなしでの高生産で作れるんだし

47 ：デフォルトの名無しさん：2017/11/04(土) 23:23:48.00 ID:b5UX6G3j.net

>>44
それ分ける意味って何なの？
わざわざ実装散らしてメンテする人に嫌がらせしたいの？

48 ：デフォルトの名無しさん：2017/11/04(土) 23:34:10.39 ID:KxJ3WBAq.net

>>47
Entity Frameworkが使えるよ
DBからエンティティクラスを自動生成できるのさ
トランザクションスクリプトの弱点は機能が重複することだから
エンティティごとにサービスクラス作ればその弱点を補える
現実的な落としどころとして最高だと考えるわけだが

49 ：デフォルトの名無しさん：2017/11/05(日) 00:21:31.23 ID:m9wZGInC.net

>>48
既存DB前提のCRUDアプリならわかるけど、それ以外の場合はどうすんの？
インピーダンスミスマッチもない前提？
DB用に正規化されたデータがUIまで貫通するの？

50 ：デフォルトの名無しさん：2017/11/05(日) 00:23:40.39 ID:sDEQ50LK.net

>>49
EntityFramework使ったことない人？

51 ：デフォルトの名無しさん：2017/11/05(日) 00:25:55.15 ID:PT/Fh6bI.net

>>50
使ったことない前提でいいから質問に回答が欲しい

52 ：デフォルトの名無しさん：2017/11/05(日) 01:38:13.55 ID:sDEQ50LK.net

>>51
正規化されたテーブルとEntityは必ずしも1:1にはならないし、そのEntityをUIでそのまま使うのはアンチパターン。

53 ：デフォルトの名無しさん：2017/11/05(日) 02:01:55.97 ID:PT/Fh6bI.net

>>52
>>48でDBから自動生成する話してるのに1:1じゃないの？
コードファーストの話してるならならわかるんだけど。

54 ：デフォルトの名無しさん：2017/11/05(日) 02:37:13.36 ID:mZtOvkfq.net

>>38
＞理想像はエクセルを機能拡張したようなもの
スマートUIの方が作りやすいが変更に弱い

＞世界のトップレベルの開発者たちがDDDを否定して
いやこれは違うぞ

欧米ではDDDのようなドメインモデルを選択してる
日本がガラパゴスで遅れてるだけ

55 ：デフォルトの名無しさん：2017/11/05(日) 02:42:39.47 ID:mZtOvkfq.net

>>45>>46
CRUDならDB＋スマートUIで良いが
複雑なドメインや変更が多いアプリはDDDが向く

＞すべてのアプケーションはDDDなしでの高生産で作れる
これは違う

スマートUIやトランザクションスクリプトの方が作りやすいが
変更に弱いので長期的には保守が大変で行き詰まってくる

56 ：デフォルトの名無しさん：2017/11/05(日) 06:59:58.30 ID:FTXfpvRm.net

>>53
自動生成したものをそのまま使うんならそうだね。普通はそんなことあまりしないけど。

57 ：デフォルトの名無しさん：2017/11/05(日) 08:00:27.84 ID:Xk9zbmTV.net

>>54
それホントなの？
外人が書いた技術書見てもトランザクションスクリプトは大抵の場合うまく行くって書いてあるよ
ドメインモデルは大抵の場合大失敗するって

58 ：デフォルトの名無しさん：2017/11/05(日) 08:03:34.39 ID:Xk9zbmTV.net

UIでエンティティをそのまま使うってめちゃくちゃなこと言ってそれを批判する自作自演論法を駆使してる人を見て頑張り屋さんだなあと思うなど

59 ：デフォルトの名無しさん：2017/11/05(日) 08:05:12.56 ID:Xk9zbmTV.net

ジャパニーズはドメインモデルを天皇か何かだと思っているのではないかと思うなど

60 ：デフォルトの名無しさん：2017/11/05(日) 08:06:45.10 ID:Xk9zbmTV.net

欧米マジ凄えからマジ

61 ：デフォルトの名無しさん：2017/11/05(日) 08:09:27.54 ID:Xk9zbmTV.net

連投すると書き込めなくなるな

62 ：デフォルトの名無しさん：2017/11/05(日) 08:18:06.55 ID:ctXS9dFl.net

天皇ってキーワードが引っ掛かったんじゃね

俺もいろいろ書き込みしてるが
決まって煽ろうとしたときだけ
なんか変ないろんなルールに引っ掛かる

実際はＡＩが仕込まれていて
都合の悪い書き込みだけルールをこじつけてはじいているのでは

63 ：デフォルトの名無しさん：2017/11/05(日) 08:23:12.21 ID:pKqy3dxV.net

日本人のDDDに対する信仰はいったいなんなんだろうな？
DDDを取り入れてない企業の若者ほどDDDに傾倒してる気がする
お前らDDDやったことないやろwww

64 ：デフォルトの名無しさん：2017/11/05(日) 08:31:03.39 ID:pKqy3dxV.net

データと振る舞いが分離して処理があちこちにばらまかれるって言う奴がいるけど
それって設計が雑でレビューもしてないだけだよね
普通に作ればトランザクションスクリプトでも疎結合高凝集になるし

65 ：デフォルトの名無しさん：2017/11/05(日) 08:35:38.15 ID:pKqy3dxV.net

ぶっちゃけ並み以上のスキルと統制力があればDDDでも貧血ドメイントランザクションスクリプトでもうまくいく
そしてそれはシステムの複雑度とは関係ない

それを踏まえて考えるとモダンなフレームワークの恩恵を受けにくいDDDは現代ではアンチパターンなんだな
フレームワークが未成熟な時代に考えられたアイデアだし時間が経って陳腐化するのは仕方がないけど

66 ：デフォルトの名無しさん：2017/11/05(日) 14:12:32.46 ID:tjXjX3Hx.net

>>65
フレームワークのロックインを避けて移植性を高めたい場合は？

67 ：デフォルトの名無しさん：2017/11/05(日) 14:25:33.60 ID:Qjn7pIjt.net

トランザクションスクリプト推しとの議論スレにじゃなくて、DDDをうまくやる方法を語れるスレになってほしいな
なんでOO系のスレってアンチが粘着しがちなんだろう

68 ：デフォルトの名無しさん：2017/11/05(日) 14:46:35.78 ID:pKqy3dxV.net

>>66
移植する予定が出てきてから考えればいいよ
現実的な線で言うとDDDにするコストより地道に移植するコストのほうが安いけどな

69 ：デフォルトの名無しさん：2017/11/05(日) 14:51:12.32 ID:pKqy3dxV.net

>>67
本当に優れた手法なら批判的な意見を正論で叩き潰せるはず
俺はそれを見てみたいんだよ
実は俺はDDDアンチじゃなく信者だからね
他人の意見は上司を説得して業務に取り入れるための参考になる
はやく論破してくれ

70 ：デフォルトの名無しさん：2017/11/05(日) 15:09:40.83 ID:SLzcUjqk.net

>>69
論破っていうけどさ、

> 現実的な線で言うとDDDにするコストより地道に移植するコストのほうが安いけどな

みたいな、根拠も示さない意見を論破する労力なんて誰も割きたくないでしょw
いや、うちはDDDで移植のコストは下がったけどな、って返せばいいの？

71 ：デフォルトの名無しさん：2017/11/05(日) 15:16:50.90 ID:pKqy3dxV.net

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

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

72 ：デフォルトの名無しさん：2017/11/05(日) 15:33:43.90 ID:SLzcUjqk.net

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

73 ：デフォルトの名無しさん：2017/11/05(日) 15:38:24.62 ID:pKqy3dxV.net

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

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

74 ：デフォルトの名無しさん：2017/11/05(日) 15:58:00.31 ID:gkj4dTGN.net

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

75 ：デフォルトの名無しさん：2017/11/05(日) 16:00:49.98 ID:pKqy3dxV.net

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

76 ：デフォルトの名無しさん：2017/11/05(日) 16:04:04.40 ID:HYpM4i0x.net

>>75
知らないだけ

77 ：デフォルトの名無しさん：2017/11/05(日) 16:04:32.12 ID:X/HC4l5L.net

>>75
具体例を

78 ：デフォルトの名無しさん：2017/11/05(日) 19:48:21.92 ID:JcEMXHd2.net

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

79 ：デフォルトの名無しさん：2017/11/05(日) 20:15:07.05 ID:34F4Igvu.net

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

80 ：デフォルトの名無しさん：2017/11/05(日) 20:21:57.83 ID:hrMLtbbu.net

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

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

81 ：デフォルトの名無しさん：2017/11/05(日) 20:29:14.50 ID:qSskq3Yv.net

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

82 ：デフォルトの名無しさん：2017/11/05(日) 21:16:49.89 ID:2uZ0aYp5.net

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

83 ：デフォルトの名無しさん：2017/11/05(日) 21:20:40.35 ID:mZtOvkfq.net

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

84 ：デフォルトの名無しさん：2017/11/05(日) 22:13:53.69 ID:mZtOvkfq.net

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

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

85 ：デフォルトの名無しさん：2017/11/06(月) 00:29:31.84 ID:P59vPp8D.net

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

86 ：デフォルトの名無しさん：2017/11/06(月) 13:22:13.87 ID:s60z57bG.net

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

87 ：デフォルトの名無しさん：2017/11/06(月) 19:18:41.19 ID:9L+ZJ2Xp.net

考えるな　感じるんだ

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


サービスだとおもいます

88 ：デフォルトの名無しさん：2017/11/10(金) 15:55:49.97 ID:WtBM3Wp4.net

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

89 ：デフォルトの名無しさん：2017/11/10(金) 21:17:00.97 ID:LsbUks3P.net

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

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

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

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

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

90 ：デフォルトの名無しさん：2017/11/12(日) 10:23:37.61 ID:j0JK3XOe.net

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

91 ：デフォルトの名無しさん：2017/11/13(月) 07:29:43.51 ID:XVC/GNte.net

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

92 ：デフォルトの名無しさん：2017/11/13(月) 08:20:06.77 ID:1kxbOfqW.net

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

93 ：デフォルトの名無しさん：2017/11/13(月) 08:41:32.54 ID:vmC6RyQT.net

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

94 ：デフォルトの名無しさん：2017/11/13(月) 09:17:00.78 ID:KJNT45pE.net

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

95 ：デフォルトの名無しさん：2017/11/13(月) 12:08:35.87 ID:1LsyXLAY.net

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

96 ：デフォルトの名無しさん：2017/11/13(月) 18:48:33.23 ID:1kxbOfqW.net

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

97 ：デフォルトの名無しさん：2017/11/13(月) 20:17:19.09 ID:IDSFIQtw.net

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

98 ：デフォルトの名無しさん：2017/11/13(月) 22:06:30.64 ID:KJNT45pE.net

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

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

99 ：デフォルトの名無しさん：2017/11/14(火) 05:47:03.90 ID:9Gbq8NEA.net

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

100 ：デフォルトの名無しさん：2017/11/14(火) 07:18:29.77 ID:R9xQaEyZ.net

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

101 ：デフォルトの名無しさん：2017/11/14(火) 19:38:43.49 ID:kwaLWx7P.net

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

102 ：デフォルトの名無しさん：2017/11/15(水) 03:47:42.79 ID:3vTQ1KLC.net

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

103 ：デフォルトの名無しさん：2017/11/16(木) 07:24:52.29 ID:yg2PUXdS.net

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

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

104 ：デフォルトの名無しさん：2017/11/16(木) 07:30:52.62 ID:DVV+REXJ.net

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

105 ：デフォルトの名無しさん：2017/11/16(木) 12:33:04.40 ID:i9LdlFRo.net

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

106 ：デフォルトの名無しさん：2017/11/17(金) 08:39:38.18 ID:jlfmLuFK.net

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

107 ：デフォルトの名無しさん：2017/11/17(金) 23:50:35.86 ID:tGAvpZAK.net

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

108 ：デフォルトの名無しさん：2017/11/18(土) 13:44:21.91 ID:VuzSnHPO.net

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

109 ：デフォルトの名無しさん：2017/11/18(土) 15:21:12.87 ID:2Obhafep.net

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

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

110 ：デフォルトの名無しさん：2017/11/18(土) 15:39:25.13 ID:5iID0bAm.net

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

111 ：デフォルトの名無しさん：2017/11/18(土) 15:47:54.83 ID:drMX1Uce.net

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

112 ：デフォルトの名無しさん：2017/11/18(土) 16:01:31.09 ID:yU1kJYiv.net

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

113 ：デフォルトの名無しさん：2017/11/19(日) 08:43:56.41 ID:9uDeEGku.net

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

114 ：デフォルトの名無しさん：2017/11/19(日) 11:30:11.10 ID:CpArH3Dx.net

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

115 ：デフォルトの名無しさん：2017/11/19(日) 12:43:48.77 ID:+HG5lDnd.net

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

116 ：デフォルトの名無しさん：2017/11/19(日) 13:09:42.41 ID:CpArH3Dx.net

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

117 ：デフォルトの名無しさん：2017/11/19(日) 13:56:40.03 ID:+HG5lDnd.net

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

118 ：デフォルトの名無しさん：2017/11/19(日) 16:15:48.08 ID:lEYmgXHF.net

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

119 ：デフォルトの名無しさん：2017/11/22(水) 15:13:08.97 ID:LuqUsrvZ.net

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

120 ：デフォルトの名無しさん：2017/11/22(水) 18:17:46.26 ID:Fja20xY7.net

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

121 ：デフォルトの名無しさん：2017/12/05(火) 00:47:41.31 ID:dpNb6B9r.net

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

122 ：デフォルトの名無しさん：2018/05/23(水) 21:07:55.14 ID:Au5e7VGg.net

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

Q3XKO

123 ：デフォルトの名無しさん：2018/07/05(木) 00:49:06.04 ID:RfoszcD2.net

ZJY

124 ：デフォルトの名無しさん：2018/09/09(日) 06:43:58.22 ID:HEZvkUhE.net

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

125 ：デフォルトの名無しさん：2018/10/08(月) 00:49:59.53 ID:Kbmtp0Cm.net

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

ぜひ参加してください！

126 ：デフォルトの名無しさん：2018/10/11(木) 20:53:29.46 ID:f3Pn3eWA.net

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

127 ：デフォルトの名無しさん：2018/10/24(水) 09:23:12.56 ID:HQt07idp.net

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

128 ：デフォルトの名無しさん：2018/10/25(木) 01:29:02.78 ID:c44lxtY/.net

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

129 ：デフォルトの名無しさん：2019/03/17(日) 12:58:39.06 ID:F89k9A+v.net

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

130 ：デフォルトの名無しさん：2019/04/25(木) 08:19:51.47 ID:NTtreDXN.net

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

131 ：デフォルトの名無しさん：2019/04/25(木) 20:00:13.26 ID:NTtreDXN.net

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

132 ：デフォルトの名無しさん：2019/05/06(月) 12:07:22.28 ID:y1ayn2s5.net

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

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

133 ：デフォルトの名無しさん：2019/06/20(木) 07:02:35.15 ID:o5P3FSwL.net

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

134 ：デフォルトの名無しさん：2019/10/11(金) 20:14:12.01 ID:hGbwA5Kq.net

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

135 ：：2019/10/12(Sat) 06:32:18 ID:RANQu5YO.net

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

136 ：：2019/10/12(Sat) 14:21:09 ID:7TGqmTiW.net

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

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

137 ：デフォルトの名無しさん：2019/11/27(水) 21:15:02.91 ID:ymKEnJ4Y.net

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

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

138 ：デフォルトの名無しさん：2019/12/22(日) 03:38:09.90 ID:n6weJVCQ.net

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

139 ：デフォルトの名無しさん：2020/02/08(土) 08:56:40 ID:YyWxF9Co.net

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

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

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

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

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

140 ：デフォルトの名無しさん：2020/02/08(土) 09:03:45 ID:YyWxF9Co.net

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

141 ：140：2020/02/08(土) 09:04:48 ID:YyWxF9Co.net

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

142 ：デフォルトの名無しさん：2020/02/08(土) 12:58:17 ID:0wE1WgKD.net

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

“python repository pattern”で検索

143 ：139：2020/02/09(日) 12:24:41 ID:dmd9x03B.net

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

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

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

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

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

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

144 ：デフォルトの名無しさん：2020/02/09(日) 20:14:19 ID:R6dJMwaP.net

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

145 ：デフォルトの名無しさん：2020/02/10(月) 00:10:18.78 ID:0IUSwyg5.net

>>144
なるほど。

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

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

146 ：デフォルトの名無しさん：2020/02/10(月) 20:33:59 ID:EqwKVKI1.net

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

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

147 ：デフォルトの名無しさん：2020/02/11(火) 10:44:43 ID:qbg35N4F.net

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

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

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

148 ：デフォルトの名無しさん：2020/02/11(火) 12:30:25.83 ID:rXVtelf6.net

リポジトリで重要なのはインターフェースと実装を分けること
インターフェースはモデル層になるけど、実装はモデル層にはなくデータベース関連の知識は実装に閉じ込める
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:
　　　　# ...

149 ：デフォルトの名無しさん：2020/02/11(火) 13:38:06 ID:v/oRLdRM.net

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

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

150 ：デフォルトの名無しさん：2020/02/11(火) 19:36:41.89 ID:Vv3Ln0ZS.net

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

151 ：デフォルトの名無しさん：2020/02/11(火) 21:46:53.70 ID:v/oRLdRM.net

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

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

152 ：デフォルトの名無しさん：2020/02/13(木) 00:19:28.03 ID:slfRt6Hj.net

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

153 ：デフォルトの名無しさん：2020/02/13(木) 02:16:39.59 ID:zqMi9kcN.net

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

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

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

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

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

154 ：デフォルトの名無しさん：2020/02/13(木) 02:20:34.42 ID:zqMi9kcN.net

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

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

155 ：デフォルトの名無しさん：2020/02/13(木) 15:23:21.01 ID:6VutC31N.net

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

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

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

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

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

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

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

156 ：デフォルトの名無しさん：2020/02/13(木) 18:03:52 ID:r7bSHOfr.net

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

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

157 ：デフォルトの名無しさん：2020/02/16(日) 13:43:23 ID:Xiaae5hS.net

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

158 ：デフォルトの名無しさん：2020/02/18(火) 21:40:17 ID:2AC9Ct1n.net

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

159 ：デフォルトの名無しさん：2020/02/19(水) 00:06:44 ID:i9qIzFMe.net

>>158
Repositoryじゃね？

160 ：デフォルトの名無しさん：2020/02/19(水) 00:14:21 ID:pJACNDga.net

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

161 ：デフォルトの名無しさん：2020/02/19(水) 01:31:27 ID:i9qIzFMe.net

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

162 ：デフォルトの名無しさん：2020/02/20(木) 22:05:54 ID:ABNkvVkH.net

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

163 ：デフォルトの名無しさん：2020/02/20(木) 23:00:47.67 ID:Nllb9nDe.net

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

164 ：デフォルトの名無しさん：2020/03/05(木) 22:14:17 ID:h922Dn8C.net

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

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

JavaやC#
RubyやPythonも

165 ：デフォルトの名無しさん：2020/03/05(木) 22:20:29 ID:h922Dn8C.net

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

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

166 ：デフォルトの名無しさん：2020/03/08(日) 23:30:12 ID:4J5clray.net

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

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

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

167 ：デフォルトの名無しさん：2020/03/08(日) 23:55:07 ID:2h+/wurX.net

作用？

168 ：デフォルトの名無しさん：2020/03/09(月) 21:19:31.81 ID:bHKN7jy6.net

左様でござる

169 ：デフォルトの名無しさん：2020/03/09(月) 22:12:07 ID:ajCpPJPb.net

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

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

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

170 ：デフォルトの名無しさん：2020/03/09(月) 22:18:06.74 ID:aVP5r6mu.net

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

171 ：デフォルトの名無しさん：2020/03/09(月) 23:12:50 ID:y1num/wG.net

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

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

172 ：デフォルトの名無しさん：2020/03/14(土) 17:55:44 ID:JKHuUiBu.net

>>171
言いたいことはわかるが、websocketみたいなコネクション管理するものを
まるまる関数型で書くなら状態変化を含んだとしてもオブジェクト的に記述した方が
多分楽。
なんでもどっちかに倒そうとすること自体が悪パターンな気がするよ。

173 ：デフォルトの名無しさん：2020/03/14(土) 18:05:14 ID:ZFQFhT9Y.net

良いとこ取りしていけ

174 ：デフォルトの名無しさん：2020/03/15(日) 00:23:36.09 ID:UpO1XTWv.net

>>172
WebSocketかー。やったことないからやってみよう

175 ：169：2020/03/15(日) 05:56:57.78 ID:1/DFOu+E.net

>>170
継承や委譲で階層構造を表現できる

まあメジャー言語はたいてい
OOのパラダイム入ってるから
だいたいできるんだけど


>>171
＞状態の数だけ型作って
＞遷移の数だけ関数つくればいいだけ

実際にはゴチャゴチャになって
「大変な労力」だから
関数型が言うほど採用されないんだよ

ただ非同期で並列化が必要な場合とか
ミッションクリティカルな場合で
バグを極力出したくない場合は別の話

176 ：デフォルトの名無しさん：2020/03/15(日) 08:25:11 ID:j83nFY2E.net

>>175
あんたに限らず関数型が大規模なプログラム書くのに向かないと思ってる層がちゃんと関数型プログラミングをしたことがなく先入観でもの言ってるのはよくわかった

177 ：デフォルトの名無しさん：2020/03/15(日) 08:38:54.73 ID:1/DFOu+E.net

>>176
あんたも決めつけで言ってるだけだろ
関数型で状態遷移を把握しづらいのは
強く実感しているし普及しない原因だ

178 ：デフォルトの名無しさん：2020/03/15(日) 09:21:24 ID:UpO1XTWv.net

>>177
それはどの言語でどんなことしようとして「強く実感」したの？

関数型言語が普及しないのは、単に先入観やOOP神話の影響で学ぼう使おうと思う人が少ないからだよ。
関数型プログラミングが普及しない理由は、当然だが関数型プログラミングの諸概念を表現するのに命令型言語が不向きだから。柔道着着て水泳するようなもんだ。

179 ：デフォルトの名無しさん：2020/03/15(日) 14:50:21 ID:7lggs81n.net

>>175
>継承や委譲で階層構造を表現できる

OOでは継承や委譲で階層構造を表現できると言われても
関数型の言語よりOO言語のほうがDDDには向いてるという論拠にはならないよ
少し古いスライドだけど、これ見て概要だけでも勉強して
https://www.slideshare.net/ScottWlaschin/domain-driven-design-with-the-f-type-system-functional-londoners-2014

180 ：デフォルトの名無しさん：2020/03/15(日) 18:32:23.77 ID:XbDoNvCk.net

一昔前のOOP厨と一緒だな。
歴史を学ばん奴は一生ループする。

181 ：デフォルトの名無しさん：2020/03/15(日) 23:47:43 ID:zobMuC0O.net

>>179 そうだよなと得心する事が多くて良い資料ですね
ドメインに継承や移譲が要るって考えてる人は是非とも読んで欲しいし、反例を挙げて欲しくなる

182 ：デフォルトの名無しさん：2020/03/16(月) 00:15:47.56 ID:PIKXUqlC.net

>>179
俺もこのスライドの作成者の本で関数型DDDに入門したクチだけど、本当にわかりやすかった
もともとHaskell, purescriptはやってて関数型には慣れてたけど、
DDDについては知らなかったので、せっかくだから関数型前提で書かれている本でと手にした。
Domain modeling made functional っていう本で、
DDDの解説はもちろん、関数型プログラミングの諸概念の解説もわかりやすく、
一冊で二度美味しい内容で、実用的な関数型プログラミングの入門書としても超おすすめ。

https://youtu.be/dEKvIxsERAI
ちなみにyoutubeにはこのスライドの発表動画もあったりする

183 ：デフォルトの名無しさん：2020/09/16(水) 23:15:57.30 ID:hC0if/qX.net

Matthias Felleisenの「How to Design Programs」を読んで関数型プログラミングに
興味を持ったものです。
次にモナドを勉強しようとしてHaskellの本を読んだがいまいちピンときません。
>>182さんが挙げられている本では、モナドを使ってモデルの実装をしているようですが、
モナドの使い方は理解できますか？

184 ：デフォルトの名無しさん：2020/09/17(木) 01:01:40.98 ID:m/PpcUvw.net

Scalaで良ければ、manning.comからでてる　Functional and Reactive Domain Modeling にモナドでドメインサービス組み立てる話が掲載されてる。
なおFree Monadをベースとしているので軽く死ねる。

https://www.manning.com/books/functional-and-reactive-domain-modeling

185 ：183：2020/09/17(木) 23:32:13.91 ID:pIiN+iyt.net

>>184
ありがとうございます・・・でもDomain modeling made functional をPDFでポチっちゃいました。
後で読もうと思います。
ところでDDDを学ぶ上で、大規模な開発経験が必要なんでしょうか？
自分は学生で、そのような経験がありません。
『How to Design Programs』では小さなプログラム作成の演習はありましたが、
それ以上の大きさのプログラム作成の方法はありませんでした。
DDDは大きなプログラムをつくるガイドになりますか？

186 ：デフォルトの名無しさん：2020/09/22(火) 23:49:46.08 ID:mxGu0eGU.net

>>184
これ

187 ：デフォルトの名無しさん：2020/09/23(水) 00:07:54.77 ID:NN2kaL4Y.net

>>184
これ読んでみようかと思ったら

＞読者は関数型言語とドメイン駆動設計に慣れている必要がある

とあるんだが、読むのにドメイン駆動設計の深ーい知識は必要だった？

188 ：デフォルトの名無しさん：2020/09/23(水) 06:16:40.99 ID:VKAwJeUe.net

DDD興味ある
大いに語るがよい

189 ：デフォルトの名無しさん：2020/09/23(水) 07:12:30.61 ID:SbRHy3fQ.net

>>187
必要最小限ではあるがScalaの文法解説と、各ドメインオブジェクトの解説は入っていたはず。
知っていれば理解が進みやすいくらいに考えてればいいはず。

190 ：デフォルトの名無しさん：2020/09/23(水) 19:36:49.05 ID:4eJQ0d8P.net

>>189
thx

191 ：デフォルトの名無しさん：2020/09/30(水) 19:59:30.09 ID:0r1wHLnO.net

DDDもそろそろバージョンアップせんと
OOPは時代遅れ

192 ：デフォルトの名無しさん：2020/12/02(水) 20:38:28.14 ID:E6FeESB6.net

Freeモナドなんて言語埋め込みDSLを作るってだけ

193 ：デフォルトの名無しさん：2020/12/05(土) 00:03:20.35 ID:FFFEgOY+.net

DDDいいよね！
なんちゃってOOPから脱出する際に役立ったよ

194 ：デフォルトの名無しさん：2021/03/09(火) 19:50:41.38 ID:rGE/nmMae

フリーランスエンジニアのエージェント毎の年収の比較【2021年2月最新】
https://coshigoto.work/freelance-engineer/1006/
フリーランス時代に月収4万円→最高340万円を達成した船越さんに、「お金」との向き合い方を聞いてみる
https://freenance.net/media/interview/1480/
フリーランスSEってどれくらい稼げるの？月単価160万円の案件を扱う定番エージェント
https://nyumon-info.com/dokuritsu/entry.html
在宅で年収１０００万稼ぐフリーランスエンジニアの稼ぎ方【再現できる】
https://hiroking.info/zaitaku-freelance-programmer-earn/
2021年最新版　エンジニアの平均年収はいくら？全体平均と比べて○○円も高い！
https://coeteco.jp/articles/11047
オリコ、ITフリーランス専用ゴールドカード「techcareer EX GOLD for Biz Card」を発行
https://www.poitan.jp/archives/77276
個人事業主待望のe-Tax送信アプリ！ 「freee」の“スマホ電子申告”が快適・便利だった
https://internet.watch.impress.co.jp/docs/review/1310717.html
エンジニアの約8割が情報のインプットに「技術ブログ」を活用
https://www.sankei.com/economy/news/210308/prl2103080419-n1.html
フリーランス向け報酬即日払いサービス『先払い』60分以内の審査回答率が90％を突破
https://thebridge.jp/prtimes/389869
フリーランスエンジニアがコード書いて稼げる上限
https://note.com/shu223/n/n5b1ef92c2edf

195 ：デフォルトの名無しさん：2021/03/31(水) 07:17:34.67 ID:PqSCUqXE.net

DDD、CQRS、イベントソーシング…
企業内システムでここまでやってるとこってあるんだろうか
参照系中心のシステムでDDDやるのは愚行？

196 ：デフォルトの名無しさん：2021/05/18(火) 06:36:21.05 ID:Z0RWJbQc.net

おれはさとった

名前がちがうだけのValueObjectクラスだけつくって
メソッド引数の位置を間違えられないようにしときゃいいんだ
それだけでいいんだ

バリデーションは入り口でやる
中は値が正しい前提でまったくチェック不要

それがDDD

197 ：デフォルトの名無しさん：2021/05/19(水) 20:38:26.97 ID:NeVz061v.net

それだけでDDDは語れないような…
いまだに集約がわからんよ

198 ：デフォルトの名無しさん：2021/05/23(日) 21:05:34.48 ID:hHIInayx.net

教科書が概念的でよくわからんことばっかほざいてる時点でおかしい
サンプルを一発提示すればああこんなのねって
それで終わるだろ！？

199 ：デフォルトの名無しさん：2021/07/13(火) 00:57:28.25 ID:FnRTq1rf.net

ガサッと取ってきて変更して全部更新！ってアホなんって思った
これの何がいいの？

200 ：デフォルトの名無しさん：2021/07/13(火) 22:24:26.83 ID:fj1E0qkc.net

CRUD で十分な単純なアプリならいらない

201 ：デフォルトの名無しさん：2021/07/14(水) 08:14:14.87 ID:wgyTk/up.net

>>198
2003年頃ならともかく。OSSのアプリが溢れている今の状況ならこのアプリのこの部分はこのパターンを使っているって示せると思う。

202 ：デフォルトの名無しさん：2021/08/10(火) 20:46:36.95 ID:R7L3+gXm.net

>>191
亀レスだが、OOPを補完するのがDDDだろうに
なんでDDDスレでOOPが時代遅れだと言えるのか疑問

203 ：デフォルトの名無しさん：2021/08/10(火) 23:57:50.00 ID:yd00h36W.net

>>202
OOPより上位レイヤーの概念なのでOOPを補完するものではないよ
Eric Evansの最初の本ではDDDの実装例としてOOPが使われただけ
関数型で実装する例もある

204 ：デフォルトの名無しさん：2021/08/11(水) 22:58:43.10 ID:AUz9CV9O.net

>>203
> OOPより上位レイヤーの概念なので
> Eric Evansの最初の本ではDDDの実装例としてOOPが使われた

そういうのを補完って言うのでは？

205 ：デフォルトの名無しさん：2021/08/12(木) 23:34:58.79 ID:1njm/kBk.net

>>204
お前は国語から勉強し直さないとこの先辛いぞ？
お前は概念とか言ってる場合じゃない

206 ：デフォルトの名無しさん：2021/08/13(金) 08:38:17.53 ID:yFah4eQP.net

ほかん
【補完】
《名・ス他》
足りない点を補って完全にすること。

OOPに足りない部分をDDDで補ってるって言いたかったのでは？
別に変だとは思えないけど

207 ：デフォルトの名無しさん：2021/08/13(金) 09:30:37.30 ID:4chv34Gy.net

OOPを補完するのがプログラミングだろうに
なんでプログラミングスレでOOPが時代遅れだと言えるのか疑問

OOPに足りない部分をプログラミングで補ってるって言いたかったのでは？

208 ：デフォルトの名無しさん：2021/08/13(金) 11:25:44.59 ID:klCtaRRF.net

OOPはプログラミングを補うものでありプログラミングがOOPを補う訳ではない

209 ：デフォルトの名無しさん：2021/08/13(金) 11:56:11.61 ID:VPbn/mvQ.net

>>206
補完などではない
そもそもOOPなどと書くから話がおかしくなる

DDDはOODを包含した概念である

210 ：デフォルトの名無しさん：2021/08/13(金) 13:49:07.82 ID:iLxHQIIJ.net

OODと言い換えたところで補完もしてなければ包含もしてない

DDDをOOの文脈でしか理解できない人は抽象概念の理解がもともと不得意なのか
日本人の書いたなんちゃってDDD本で分かったつもりになってるか
そもそもOO以外を知らないか

211 ：デフォルトの名無しさん：2021/08/13(金) 14:28:21.12 ID:klCtaRRF.net

お前はDDDを学んでもOOP及びOODには何の影響もないみたいだけど、俺は別にDDDで学んだ知識がOOP／OODに役立ってるので、別にどうでもいいっす。
なんで役立ったのか想像できないのなら、その程度ってことでしょう。

212 ：デフォルトの名無しさん：2021/08/13(金) 15:21:02.98 ID:cdK9y9f/.net

ブホッw

213 ：デフォルトの名無しさん：2021/08/14(土) 07:58:11.46 ID:3YTtOTVG.net

OOPにありがちな、車やエンジンを例にした説明より
DDDの方がしっくりくるというか
あ、OOPでこんなことができるのかと目から鱗だったな

214 ：デフォルトの名無しさん：2021/08/14(土) 15:27:00.83 ID:db9EEEoY.net

いつの時代になってもITの方法論は「方法論オナニストに都合のよい飯の種」の域を出ない

215 ：デフォルトの名無しさん：2021/08/14(土) 15:31:45.91 ID:4CNv29yk.net

建設業のように国が規格を決めてしまえばよかったんだ
国所属の認定団体に承認された関数以外使ってはいけません

216 ：デフォルトの名無しさん：2021/09/16(木) 15:51:11.37 ID:PMPdG/+a.net

DDDとは、「ドメイン知識(モデル)」を「駆動」して「開発」する開発手法であって、何か特定のアーキテクチャをあらわすものではない

217 ：デフォルトの名無しさん：2021/09/16(木) 15:54:48.85 ID:PMPdG/+a.net

嘘言いました
最後のDはDevelopmentじゃなくてDesignだったわ
恥ずかしー

218 ：デフォルトの名無しさん：2021/09/16(木) 19:58:10.14 ID:d3wmnSJn.net

もーやだー

219 ：デフォルトの名無しさん：2021/09/26(日) 11:30:18.78 ID:0AJzxi3v.net

設計はアーキテクチャを示すものじゃない
言葉が違えば意味が違う

220 ：デフォルトの名無しさん：2022/05/07(土) 06:20:48.85 ID:Japg54lQ.net

DDDは大量データ更新に弱い
10万件のレコードに同じ値をセットする処理に途方もなく時間がかかる

221 ：デフォルトの名無しさん：2022/07/27(水) 17:37:37.82 ID:hi2YYXJ0.net

カルト宗教だよね
設計というのはパフォーマンス要件の整理と実現に当たってのアーキテクチャを考えるために必要なわけで
機能要件にSLAがないだなんてことは設計するならばありえないし、
じゃあその要件に到達するためにシステムやミドルウェアをどう使っていくかがアーキテクトの肝なところじゃん
APPサーバに閉じた議論しかしてない時点で雑魚システムしか作れんし
雑魚システムにそもそも設計なんざいらんだろって話よ

こういう連中が言い出しそうなこと、DBは抽象化できる
そもそもファイルを保存するならテキストでもいい
依存性の逆転を駆使すればインタフェースに依存させることができるので、アプリから実装詳細が消える！

それでDBがやってくれてるトランザクション制御や成約、整合性の解決を
ファイルシステムで実装するその実装を誰が書くの？
アーキテクトを自称するなら君が書くってことだけど、いったい誰がそんなこと頼んだんだろう

222 ：デフォルトの名無しさん：2022/07/27(水) 17:39:26.99 ID:hi2YYXJ0.net

型システムの理解も貧弱、DBMSの理解も貧弱、なんならネットワーク・プロトコルの理解も貧弱

一生システム完成させる気ないやる気なしエンジニアの最後の拠り所だろ

223 ：デフォルトの名無しさん：2022/07/27(水) 20:57:03.92 ID:i1UDtnj5.net

だいぶ詳しい反論だなw

224 ：デフォルトの名無しさん：2022/07/27(水) 21:51:14.18 ID:gDp6GlMI.net

https://enterprisecraftsmanship.com/posts/ddd-bulk-operations/
DDDでバルク処理
そこまで拘らなくていいんじゃないかなと言う感想

225 ：デフォルトの名無しさん：2023/09/22(金) 05:22:44.35 ID:dV2V1da1.net

これってどうやって気にするの？

226 ：デフォルトの名無しさん：2023/09/28(木) 03:45:15.07 ID:i8VmgZE9.net

ｺﾞｼｺﾞｼ(-_＼)(/_-)三( ﾟДﾟ) ｽ､ｽｹﾞｰ!

227 ：デフォルトの名無しさん：2023/12/03(日) 23:52:03.41 ID:p5/cY/Es.net

テスト

228 ：デフォルトの名無しさん：2024/01/13(土) 12:32:01.04 ID:xr3OUtayB

四六時中飛ばしてる伊丹−羽田を1回飛は゛すたびに7000kWh火力発電した際に発生するのと同等のCO2を排出
四六時中飛は゛してる新千歳−羽田を1回飛ばすたびに14000kWh火カ發電した際に発生するのと同等のCO2を排出
四六時中飛ばしてる成田ークソウルを1回飛ばすたびに28000KWh火力発電した際に発生するのと同等のCO2を排出
毎曰燃料がなくなるたびに乗り換えてるクソポリヘリ夕ンク２000Lで10000kWh火力発電した際に発生するのと同等のCO2を排出
要するにこれほどの發電能力をクソ航空機に無駄に廃棄させながら増税に原発放射能汚染利権に戦争利権にと拡大してるのが岸田文雄な
四六時中猥褻がらみで逮捕されながら望遠カメラで女風呂やらのぞき見して遊ひ゛倒して莫大な温室効果ガスまき散らして木造家屋密集地上空を
平然と飛ばして墜落して一帯燃やし尽くして皆殺しにする危険極まりない行為を繰り返してる威力業務妨害災害惹起税金泥棒警視庁ヘリや
地球破壊の権化小池デタラメ百合孑のヱシ゛プ├旅行費や岸田異次元増税文雄の世界−周地球破壞費を違法にしないとダメ絶対
［ref.) ttps://www.call4.jp/info.Рhp?Τуpe=iΤems&id=I00000６2
ttРs://haneda-ｐrojecт.jimdofree.com/ , ttPs://flighT-route.Ｃom/
ttΡs://n-souonhigaisosyoudan.amebaownd.Сom／