【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/10/24(火) 19:42:47.43

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

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

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

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

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

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

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

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

第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——パターンを統合する：シェア算

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

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

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

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

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

第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——レガシー予約アプリケーション
　　　　　　訓話

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

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

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

第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）
　　　深いモデルの蒸留
　　　リファクタリングの対象を選ぶ

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

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

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

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

結論

　　　エピローグ
　　　展望

**デフォルトの名無しさん** · 2017/10/25(水) 19:04:27.51

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

**デフォルトの名無しさん** · 2017/10/25(水) 19:08:44.29

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

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

**デフォルトの名無しさん** · 2017/10/25(水) 19:31:11.15

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

**デフォルトの名無しさん** · 2017/10/25(水) 19:49:21.67

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

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

**デフォルトの名無しさん** · 2017/10/25(水) 20:12:30.45

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

**デフォルトの名無しさん** · 2017/10/25(水) 20:15:43.64

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

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

**デフォルトの名無しさん** · 2017/10/25(水) 21:51:00.68

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

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

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

**デフォルトの名無しさん** · 2017/10/27(金) 20:24:53.95

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

**デフォルトの名無しさん** · 2017/10/27(金) 20:35:29.16

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

**デフォルトの名無しさん** · 2017/10/28(土) 00:06:52.32

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

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

**デフォルトの名無しさん** · 2017/10/29(日) 22:40:08.05

ドメインて何ですか

**デフォルトの名無しさん** · 2017/10/29(日) 22:58:36.50

問題領域

**デフォルトの名無しさん** · 2017/10/30(月) 12:05:58.95

何が問題なんですか？

**デフォルトの名無しさん** · 2017/10/30(月) 12:06:24.63

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

**デフォルトの名無しさん** · 2017/11/03(金) 08:47:57.76

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

**デフォルトの名無しさん** · 2017/11/03(金) 08:53:45.98

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

**デフォルトの名無しさん** · 2017/11/03(金) 09:43:41.21

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

根本的に間違ってるだろ

**デフォルトの名無しさん** · 2017/11/03(金) 10:22:22.91

根本的な正解をヨロシク

**デフォルトの名無しさん** · 2017/11/03(金) 10:33:38.13

俺も宜しく。

**デフォルトの名無しさん** · 2017/11/03(金) 14:11:54.12

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

**デフォルトの名無しさん** · 2017/11/04(土) 03:13:26.11

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

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

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

**デフォルトの名無しさん** · 2017/11/04(土) 08:52:57.07

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/11/04(土) 09:24:40.15

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

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

読み出しは自由

**デフォルトの名無しさん** · 2017/11/04(土) 13:26:31.92

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

**デフォルトの名無しさん** · 2017/11/04(土) 13:40:02.20

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

**デフォルトの名無しさん** · 2017/11/04(土) 14:50:46.68

論理的推論（ろんりてきすいろん、英: 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

**デフォルトの名無しさん** · 2017/11/04(土) 18:46:52.01

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

**デフォルトの名無しさん** · 2017/11/04(土) 19:11:47.69

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

**デフォルトの名無しさん** · 2017/11/04(土) 21:10:36.19

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

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

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

**デフォルトの名無しさん** · 2017/11/04(土) 23:23:48.00

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

**デフォルトの名無しさん** · 2017/11/04(土) 23:34:10.39

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

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/11/05(日) 02:01:55.97

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

**デフォルトの名無しさん** · 2017/11/05(日) 02:37:13.36

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

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

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

**デフォルトの名無しさん** · 2017/11/05(日) 02:42:39.47

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

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

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

**デフォルトの名無しさん** · 2017/11/05(日) 06:59:58.30

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

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

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

**デフォルトの名無しさん** · 2017/11/05(日) 08:03:34.39

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

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

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

**デフォルトの名無しさん** · 2017/11/05(日) 08:06:45.10

欧米マジ凄えからマジ

**デフォルトの名無しさん** · 2017/11/05(日) 08:09:27.54

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

**デフォルトの名無しさん** · 2017/11/05(日) 08:18:06.55

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

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

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

**デフォルトの名無しさん** · 2017/11/05(日) 08:23:12.21

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

**デフォルトの名無しさん** · 2017/11/05(日) 08:31:03.39

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

**デフォルトの名無しさん** · 2017/11/05(日) 08:35:38.15

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

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

**デフォルトの名無しさん** · 2017/11/05(日) 14:12:32.46

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

**デフォルトの名無しさん** · 2017/11/05(日) 14:25:33.60

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

**デフォルトの名無しさん** · 2017/11/05(日) 14:46:35.78

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

**デフォルトの名無しさん** · 2017/11/05(日) 14:51:12.32

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

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

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

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

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

**デフォルトの名無しさん** · 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
モデルビューコントローラはレイヤじゃ無いのか
そう言えばモデル層とか聞かないね