◎正当な理由による書き込みの削除について:      生島英之とみられる方へ:

【DDD】ドメイン駆動設計【エリック・エヴァンス】 YouTube動画>1本


動画、画像抽出 || この掲示板へ 類似スレ 掲示板一覧 人気スレ 動画人気順

このスレへの固定リンク: http://5chb.net/r/tech/1508841546/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

1デフォルトの名無しさん
2017/10/24(火) 19:39:06.49ID:jO+jDbIG
第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.31ID:vrotHuwu
>>1
いきなり目次って
ここ読書スレ?
3デフォルトの名無しさん
2017/10/24(火) 19:40:53.73ID:jO+jDbIG
第2部 モデル駆動設計の構成要素

第4章 ドメインを隔離する
   レイヤ化アーキテクチャ(LAYERED ARCHITECTURE)
      例4.1——オンラインバンキングの機能をレイヤに分割する
      レイヤを関係づける
      アーキテクチャフレームワーク
   ドメイン層はモデルが息づく場所
   利口なUI「アンチパターン」(SMART UI メANTI-PATTERNモ)
   その他の隔離
4デフォルトの名無しさん
2017/10/24(火) 19:41:31.02ID:jO+jDbIG
第5章 ソフトウェアで表現されたモデル
   関連
      例5.1——証券取引口座における関連
   エンティティ(ENTITIES)(別名 参照オブジェクト(REFERENCE OBJECTS))
      エンティティをモデル化する
      同一性のための操作を設計する
   値オブジェクト(VALUE OBJECTS)
      値オブジェクトを設計する
      例5.2——値オブジェクトを使ってデータベースをチューニングする
      値オブジェクトを含む関連を設計する
   サービス(SERVICES)
      サービスと隔離されたドメイン層
      粒度
      サービスへのアクセス
   モジュール(MODULES)(別名 パッケージ(PACKAGES))
      アジャイルモジュール
      例5.3——Javaにおけるパッケージのコーディング規約
      インフラストラクチャ駆動パッケージングの落とし穴
   モデリングパラダイム
      なぜオブジェクトパラダイムが主流なのか?
      オブジェクトの世界におけるオブジェクトではないもの
      パラダイムを混在させる際にはモデル駆動設計に忠実であること
5デフォルトの名無しさん
2017/10/24(火) 19:42:12.50ID:jO+jDbIG
第6章 ドメインオブジェクトのライフサイクル
   集約(AGGREGATES)
      例6.1——購入注文の整合性
   ファクトリ(FACTORIES)
      ファクトリとその場所を選択する
      コンストラクタがあればよい場合
      インタフェースを設計する
      不変条件のロジックはどこへ置くべきか?
      エンティティファクトリ対値オブジェクトファクトリ
      格納したオブジェクトを再構成する
   リポジトリ(REPOSITORIES)
      リポジトリに対して問い合わせる
      クライアントのコードはリポジトリの実装を無視するが、開発者はそうではない
      リポジトリを実装する
      フレームワークの範囲内で作業する
      ファクトリとの関係
   関係データベースに合わせてオブジェクトを設計する
6デフォルトの名無しさん
2017/10/24(火) 19:42:47.43ID:jO+jDbIG
第7章 言語を使用する:応用例
   貨物輸送システムを導入する
   ドメインを隔離する:アプリケーションの導入
   エンティティと値オブジェクトを区別する
      役割とその他の属性
   輸送ドメインの関連を設計する
   集約の境界
   リポジトリを選択する
   シナリオをウォークスルーする
      サンプルアプリケーションの機能:貨物の荷出し地を変更する
      サンプルアプリケーションの機能:リピータへの対応
   オブジェクトの生成
      貨物用のファクトリとコンストラクタ
      荷役イベントを追加する
   リファクタリングのために立ち止まる:貨物集約についてのもう1つの設計
   輸送モデルにおけるモジュール
   新機能を導入する:配分チェック
      2つのシステムを接続する
      モデルを強化する:ビジネスのセグメント化
      パフォーマンスチューニング
   最後に
7デフォルトの名無しさん
2017/10/24(火) 19:43:20.05ID:jO+jDbIG
第3部 より深い洞察へ向かうリファクタリング

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

第8章 ブレイクスルー
   ブレイクスルーの話
      悪くないモデルなのだが…
      ブレイクスルー
      さらに深いモデル
      冷静な意思決定
      結末
   好機
   基本への集中
   エピローグ:新しい洞察の連鎖
8デフォルトの名無しさん
2017/10/24(火) 19:43:49.53ID:jO+jDbIG
第9章 暗黙的な概念を明示的にする
   概念を掘り出す
      言葉に耳を傾ける
      例9.1——輸送モデルに欠けている概念を聞き分ける
      ぎこちなさを精査する
      例9.2——利息を得る 難しい方法
      矛盾について熟考する
      文献を読む
      例9.3——利息を得る 文献を用いた場合
      何度でも挑戦すること
   それほど明白でない概念をモデル化する方法
      明示的な制約
      例9.4——再考:オーバーブッキングポリシー
      ドメインオブジェクトとしてのプロセス
   仕様(SPECIFICATION)
      仕様の適用と実装
      例9.5——化学製品倉庫での格納
      例9.6——倉庫内格納サービスの、実際に動作するプロトタイプ
9デフォルトの名無しさん
2017/10/24(火) 19:44:14.81ID:jO+jDbIG
第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.64ID:jO+jDbIG
第11章 アナリシスパターンを適用する
      例11.1——利息を得る 勘定を用いた場合
      例11.1(続き)——夜間バッチについての洞察
      アナリシスパターンは活用すべき知識である

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

第13章 より深い洞察へ向かうリファクタリング
   開始
   探究チーム
   先達の技
   開発者のための設計
   タイミング
   好機となる危機
11デフォルトの名無しさん
2017/10/24(火) 19:45:17.29ID:jO+jDbIG
第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.94ID:jO+jDbIG
   別々の道(SEPARATE WAYS)
      例14.5——保険プロジェクトの縮小化
   公開ホストサービス(OPEN HOST SERVICE)
   公表された言語(PUBLISHED LANGUAGE)
      例14.6——化学のための公表された言語
   象のモデルを統一する
      モデルコンテキスト戦略を選択する
      チームでの意思決定と、より上層での意思決定
      コンテキストに自らの身を置く
      境界を変換する
      変更できないものを受け入れる:外部システムの輪郭を描く
      外部システムとの関係
      設計中のシステム
      別のモデルで特殊な要求を満たす
      デプロイ
      トレードオフ
      すでにプロジェクトが進行中の場合
   変換
      コンテキストをマージする:別々の道 → 共有カーネル
      コンテキストをマージする:共有カーネル → 継続的な統合
      レガシーシステムを段階的に廃止する
      公開ホストサービス → 公表された言語
13デフォルトの名無しさん
2017/10/24(火) 19:46:02.22ID:jO+jDbIG
第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.33ID:jO+jDbIG
第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.01ID:jO+jDbIG
第17章 戦略をまとめ上げる
   大規模な構造と境界づけられたコンテキストを組み合わせる
   大規模な構造と蒸留を組み合わせる
   まず評価する
   誰が戦略を策定するのか?
      アプリケーション開発から現れる構造
      顧客に焦点を合わせたアーキテクチャチーム
   戦略的設計上の意思決定を行うために欠かせない6つのこと
      同じことが技術的なフレームワークにも当てはまる
      マスタプランに注意すること

結論

   エピローグ
   展望
16デフォルトの名無しさん
2017/10/25(水) 19:04:27.51ID:44Xm0aVs
「境界づけられたコンテキスト」が
何のことかよくわからないので教えてください。
17デフォルトの名無しさん
2017/10/25(水) 19:08:44.29ID:aatZ8FSF
>「境界づけられたコンテキスト」
ユビキタス言語の文脈が変わる境界のこと

たとえば「アカウント」は
金融なら口座だけど
Webサービスなら登録情報とか
18デフォルトの名無しさん
2017/10/25(水) 19:31:11.15ID:44Xm0aVs
>17
その境界はパッケージとかディレクトリとかで判断せよ
みたいな感じ?
19デフォルトの名無しさん
2017/10/25(水) 19:49:21.67ID:aatZ8FSF
>>18
DDDなら最初にまずドメインで判断すべき
どこまでが開発するドメインの範囲なのかって

Webサービスで通販やんないから
お金や口座は絡まないけど
ログインするタイプのサービスだとか
20デフォルトの名無しさん
2017/10/25(水) 20:12:30.45ID:44Xm0aVs
>>19
あーそうか、
Webサービスの場合、コンパイルしてバイナリ化しないから、
PHPの場合配備するAppはディレクトリ構造まんまになるんだけど、
システムの境界はどうやって判断するの?
設計図上でしか判断し得ないの?
サーバマシンの区切り? ディレクトリの区切り? URLのドメイン名の
区切り? その「DDDのあるドメイン」って実際のファイルシステム上では
どのように区切るの?
21デフォルトの名無しさん
2017/10/25(水) 20:15:43.64ID:aatZ8FSF
>>20
コンテキストの境界をシステムで表現する際には
(Javaなら)パッケージとその名前空間を使う

でもあくまでビジネスのドメインが先にあって
それにシステムを合わせるのであって
システムだけで判断したらダメだからね
22デフォルトの名無しさん
2017/10/25(水) 21:51:00.68ID:0GYD+24d
「境界づけられたコンテキスト」は組織構造やシステム構成でも変わりうるよ
特に組織構造への依存度は高いのでそれに応じたいくつかの戦略パターンが解説されてる

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

企業全体で統一された一つのモデルや用語集を作ろうとするのではなく
コンテキスト境界に閉じた中でモデルや語彙を明確にしようというのがDDDの考え方
23デフォルトの名無しさん
2017/10/27(金) 20:24:53.95ID:BY+fhh/f
実装とか物理設計の話になってすまないけど、
DBMSの「テーブルが所属するDB名の境界」が
上記の「境界づけられたコンテキストの」「境界」
に当たるのだろうか。
24デフォルトの名無しさん
2017/10/27(金) 20:35:29.16ID:NaPnvd1g
コンテキストとDBインスタンスを一致させてる
25デフォルトの名無しさん
2017/10/28(土) 00:06:52.32ID:EvuLUtue
>>23
一般的には当たらないことのほうが多いと思う
>>22の例で受注と出荷で違うコンテキストだったとしても
同じDBに属するテーブルを使うことはよくあるし
逆に複数のDBがひとつのコンテキストに属することもある

モデルやユビキタス言語のスコープが境界づけられたコンテキスト
境界は自然に決まるものじゃないから設計者がドメイン分析の過程で決めていくしかない
26デフォルトの名無しさん
2017/10/29(日) 22:40:08.05ID:CrDMqcML
ドメインて何ですか
27デフォルトの名無しさん
2017/10/29(日) 22:58:36.50ID:RyqL6Q1z
問題領域
28デフォルトの名無しさん
2017/10/30(月) 12:05:58.95ID:5RpC60IR
何が問題なんですか?
29デフォルトの名無しさん
2017/10/30(月) 12:06:24.63ID:5RpC60IR
トラブルエリアじゃ駄目なんですか?
30デフォルトの名無しさん
2017/11/03(金) 08:47:57.76ID:0WQ4WnED
大雑把に言うと、クラス名やメソッド名、変数名を使って仕事の会話を
しましょうと言うだけ。その逆も然り、それで違和感を感じたら設計や
用語を見直す。
31デフォルトの名無しさん
2017/11/03(金) 08:53:45.98ID:0WQ4WnED
バリューオブジェクトやエンティティとかリポジトリィとかは単なる設計/実装テクニック。
32デフォルトの名無しさん
2017/11/03(金) 09:43:41.21ID:Ro85MhDs
>>30
>クラス名やメソッド名、変数名を使って仕事の会話をしましょうと言うだけ。

根本的に間違ってるだろ
33デフォルトの名無しさん
2017/11/03(金) 10:22:22.91ID:wXWM393A
根本的な正解をヨロシク
34デフォルトの名無しさん
2017/11/03(金) 10:33:38.13ID:BtRYOGnT
俺も宜しく。
35デフォルトの名無しさん
2017/11/03(金) 14:11:54.12ID:CsNI9L5l
ビューモデル、データモデルとドメインモデルとの相互変換がめんどくさすぎる
バリューオブジェクトと集約ルートの考え方のせいで自動マッピング全然効かなくなるし
36デフォルトの名無しさん
2017/11/04(土) 03:13:26.11ID:b5UX6G3j
正直O/Rマッパーで取ってきたデータの入れ物をこねくり回す方が100倍楽なんだが、
大規模プロジェクトや長期のメンテが必要な場合以外でDDD使うケースってどれぐらいあるんだろ?
37デフォルトの名無しさん
2017/11/04(土) 05:04:45.77ID:7D9PjzRB
お前らががO/Rマッパーの中身を作ったことがあるならいいけど
そうじゃないと、その便利なO/Rマッパーに自分の技術者としての
存在価値を食い殺されることになるから気をつけろ。
DIY: 1度は作れ。最初から既存の便利なものは買うな、取り寄せるな。
DRY: 同じモノは2度も作るな。
つまり「自分の力で1度だけ作れ。」
0回もダメ, 2回以上同じモノを何度も作るのもダメ。
38デフォルトの名無しさん
2017/11/04(土) 08:52:57.07ID:/k8c/hp8
DDDってこんな感じじゃん?

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

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

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

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

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

MicrosoftもそれがわかってるからASP.NET MVCやEFのようなフレームワークを作った
ビューモデル、データモデルは振る舞いを持たない素朴なデータの集合の方がわかりやすいし楽だと割り切った
そして検証の工数を下げるために属性バリデーションが発達した
これは他の言語でもだいたい同じ
世界のトップレベルの開発者たちがDDDを否定して貧血ドメイン+強力な検証というパターンを選択した
39デフォルトの名無しさん
2017/11/04(土) 09:24:40.15ID:4lDAx3zT
今の仕事ドメインもどきの実装になってる

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

読み出しは自由
40デフォルトの名無しさん
2017/11/04(土) 13:26:31.92ID:O0AU1SEY
>>38
どこでどう勘違いしたらそんな理解になるの?
41デフォルトの名無しさん
2017/11/04(土) 13:40:02.20ID:/k8c/hp8
>>40
反論は最低限、論理的にお願いします
42デフォルトの名無しさん
2017/11/04(土) 14:50:46.68ID:7D9PjzRB
論理的推論(ろんりてきすいろん、英: 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.01ID:/k8c/hp8
反論はないということですね
やっぱりDDDはアンチパターンなんだ
44デフォルトの名無しさん
2017/11/04(土) 19:11:47.69ID:KxJ3WBAq
貧血ドメインごとに専用のサービスクラスを作るのはトランザクションスクリプト?
45デフォルトの名無しさん
2017/11/04(土) 21:10:36.19ID:Yu+eR6Tn
>>43
DDDの提唱者ですら言ってるよ
ビジネスロジックが複雑でないドメイン、例えばただのCRUDみたいに、
DBのUIでしかないようなアプリはDDDでやる意味ないって
46デフォルトの名無しさん
2017/11/04(土) 21:21:57.79ID:/k8c/hp8
>>45
その複雑なドメインってのがそもそも現実的じゃないんだよ
すべてのアプケーションはDDDなしでの高生産で作れるんだし
47デフォルトの名無しさん
2017/11/04(土) 23:23:48.00ID:b5UX6G3j
>>44
それ分ける意味って何なの?
わざわざ実装散らしてメンテする人に嫌がらせしたいの?
48デフォルトの名無しさん
2017/11/04(土) 23:34:10.39ID:KxJ3WBAq
>>47
Entity Frameworkが使えるよ
DBからエンティティクラスを自動生成できるのさ
トランザクションスクリプトの弱点は機能が重複することだから
エンティティごとにサービスクラス作ればその弱点を補える
現実的な落としどころとして最高だと考えるわけだが
49デフォルトの名無しさん
2017/11/05(日) 00:21:31.23ID:m9wZGInC
>>48
既存DB前提のCRUDアプリならわかるけど、それ以外の場合はどうすんの?
インピーダンスミスマッチもない前提?
DB用に正規化されたデータがUIまで貫通するの?
50デフォルトの名無しさん
2017/11/05(日) 00:23:40.39ID:sDEQ50LK
>>49
EntityFramework使ったことない人?
51デフォルトの名無しさん
2017/11/05(日) 00:25:55.15ID:PT/Fh6bI
>>50
使ったことない前提でいいから質問に回答が欲しい
52デフォルトの名無しさん
2017/11/05(日) 01:38:13.55ID:sDEQ50LK
>>51
正規化されたテーブルとEntityは必ずしも1:1にはならないし、そのEntityをUIでそのまま使うのはアンチパターン。
53デフォルトの名無しさん
2017/11/05(日) 02:01:55.97ID:PT/Fh6bI
>>52
>>48でDBから自動生成する話してるのに1:1じゃないの?
コードファーストの話してるならならわかるんだけど。
54デフォルトの名無しさん
2017/11/05(日) 02:37:13.36ID:mZtOvkfq
>>38
>理想像はエクセルを機能拡張したようなもの
スマートUIの方が作りやすいが変更に弱い

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

欧米ではDDDのようなドメインモデルを選択してる
日本がガラパゴスで遅れてるだけ
55デフォルトの名無しさん
2017/11/05(日) 02:42:39.47ID:mZtOvkfq
>>45>>46
CRUDならDB+スマートUIで良いが
複雑なドメインや変更が多いアプリはDDDが向く

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

スマートUIやトランザクションスクリプトの方が作りやすいが
変更に弱いので長期的には保守が大変で行き詰まってくる
56デフォルトの名無しさん
2017/11/05(日) 06:59:58.30ID:FTXfpvRm
>>53
自動生成したものをそのまま使うんならそうだね。普通はそんなことあまりしないけど。
57デフォルトの名無しさん
2017/11/05(日) 08:00:27.84ID:Xk9zbmTV
>>54
それホントなの?
外人が書いた技術書見てもトランザクションスクリプトは大抵の場合うまく行くって書いてあるよ
ドメインモデルは大抵の場合大失敗するって
58デフォルトの名無しさん
2017/11/05(日) 08:03:34.39ID:Xk9zbmTV
UIでエンティティをそのまま使うってめちゃくちゃなこと言ってそれを批判する自作自演論法を駆使してる人を見て頑張り屋さんだなあと思うなど
59デフォルトの名無しさん
2017/11/05(日) 08:05:12.56ID:Xk9zbmTV
ジャパニーズはドメインモデルを天皇か何かだと思っているのではないかと思うなど
60デフォルトの名無しさん
2017/11/05(日) 08:06:45.10ID:Xk9zbmTV
欧米マジ凄えからマジ
61デフォルトの名無しさん
2017/11/05(日) 08:09:27.54ID:Xk9zbmTV
連投すると書き込めなくなるな
62デフォルトの名無しさん
2017/11/05(日) 08:18:06.55ID:ctXS9dFl
天皇ってキーワードが引っ掛かったんじゃね

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

実際はAIが仕込まれていて
都合の悪い書き込みだけルールをこじつけてはじいているのでは
63デフォルトの名無しさん
2017/11/05(日) 08:23:12.21ID:pKqy3dxV
日本人のDDDに対する信仰はいったいなんなんだろうな?
DDDを取り入れてない企業の若者ほどDDDに傾倒してる気がする
お前らDDDやったことないやろwww
64デフォルトの名無しさん
2017/11/05(日) 08:31:03.39ID:pKqy3dxV
データと振る舞いが分離して処理があちこちにばらまかれるって言う奴がいるけど
それって設計が雑でレビューもしてないだけだよね
普通に作ればトランザクションスクリプトでも疎結合高凝集になるし
65デフォルトの名無しさん
2017/11/05(日) 08:35:38.15ID:pKqy3dxV
ぶっちゃけ並み以上のスキルと統制力があればDDDでも貧血ドメイントランザクションスクリプトでもうまくいく
そしてそれはシステムの複雑度とは関係ない

それを踏まえて考えるとモダンなフレームワークの恩恵を受けにくいDDDは現代ではアンチパターンなんだな
フレームワークが未成熟な時代に考えられたアイデアだし時間が経って陳腐化するのは仕方がないけど
66デフォルトの名無しさん
2017/11/05(日) 14:12:32.46ID:tjXjX3Hx
>>65
フレームワークのロックインを避けて移植性を高めたい場合は?
67デフォルトの名無しさん
2017/11/05(日) 14:25:33.60ID:Qjn7pIjt
トランザクションスクリプト推しとの議論スレにじゃなくて、DDDをうまくやる方法を語れるスレになってほしいな
なんでOO系のスレってアンチが粘着しがちなんだろう
68デフォルトの名無しさん
2017/11/05(日) 14:46:35.78ID:pKqy3dxV
>>66
移植する予定が出てきてから考えればいいよ
現実的な線で言うとDDDにするコストより地道に移植するコストのほうが安いけどな
69デフォルトの名無しさん
2017/11/05(日) 14:51:12.32ID:pKqy3dxV
>>67
本当に優れた手法なら批判的な意見を正論で叩き潰せるはず
俺はそれを見てみたいんだよ
実は俺はDDDアンチじゃなく信者だからね
他人の意見は上司を説得して業務に取り入れるための参考になる
はやく論破してくれ
70デフォルトの名無しさん
2017/11/05(日) 15:09:40.83ID:SLzcUjqk
>>69
論破っていうけどさ、

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

みたいな、根拠も示さない意見を論破する労力なんて誰も割きたくないでしょw
いや、うちはDDDで移植のコストは下がったけどな、って返せばいいの?
71デフォルトの名無しさん
2017/11/05(日) 15:16:50.90ID:pKqy3dxV
>>70
移植先のフレームワークも似たような機能が揃ってるから大した手間にならん
フレームワークに沿って高生産の仕事を2回やるだけ
しかもフレームワークは似てるので2回目はさらに簡単

生産性をあげるのがフレームワークだ
それに逆らってDDDをやっても生産性を下げるだけ
移植するときにもまた他のフレームワークに逆らうことになり生産性を下げざるをえない
苦痛を2回も強いられる
72デフォルトの名無しさん
2017/11/05(日) 15:33:43.90ID:SLzcUjqk
まず、DDDはフレームワークに逆らっている、というのがよくわからん
具体的にはどういうこと?
73デフォルトの名無しさん
2017/11/05(日) 15:38:24.62ID:pKqy3dxV
>>72
フレームワークを使った開発ではプレーンなオブジェクトに属性を付けて不変条件を守るスタイルが優勢

DDDは余計なメンバを公開しないしインフラから切り離すので属性にも依存したくない
フレームワークの利点を潰してしまう
74デフォルトの名無しさん
2017/11/05(日) 15:58:00.31ID:gkj4dTGN
具体的なフレームワーク名も挙げずに何言ってんのこいつ
75デフォルトの名無しさん
2017/11/05(日) 16:00:49.98ID:pKqy3dxV
>>74
最近のフレームワークはどれも同じようなものって言ってるだろ
なら具体的にあげる意味はないね
76デフォルトの名無しさん
2017/11/05(日) 16:04:04.40ID:HYpM4i0x
>>75
知らないだけ
77デフォルトの名無しさん
2017/11/05(日) 16:04:32.12ID:X/HC4l5L
>>75
具体例を
78デフォルトの名無しさん
2017/11/05(日) 19:48:21.92ID:JcEMXHd2
サービス層とMVCのコントローラは何が違うのか
情弱の俺に教えてくれよ。
79デフォルトの名無しさん
2017/11/05(日) 20:15:07.05ID:34F4Igvu
>>68
最初から予定してる場合は?
80デフォルトの名無しさん
2017/11/05(日) 20:21:57.83ID:hrMLtbbu
>>78
サービスって言葉は色んな意味で使われるから分かりにくい
特定のクラスに属するとマズイ処理を実装するところだと理解してるけど

MVCのCはそのまんまUIとモデルの橋渡しでしょ
81デフォルトの名無しさん
2017/11/05(日) 20:29:14.50ID:qSskq3Yv
ドメインモデルっていうくらいなんだから
サービスドメインはモデルでしょうな
82デフォルトの名無しさん
2017/11/05(日) 21:16:49.89ID:2uZ0aYp5
>>63
その割にはドメインに対する理解とかには全然注力しない印象。
業務系だったら、簿記や会計の勉強したりとか。
83デフォルトの名無しさん
2017/11/05(日) 21:20:40.35ID:mZtOvkfq
>>67
>OO系のスレってアンチが粘着しがち
OOが難しいから否定したいんだろう
関数型のスレにもいるだろ
84デフォルトの名無しさん
2017/11/05(日) 22:13:53.69ID:mZtOvkfq
>>78
似てるけど微妙に違う

Mにドメイン層とインフラ層が一緒になってるのは分かるよな
サービス(アプリ)層はCとMの一部が一緒になってる
85デフォルトの名無しさん
2017/11/06(月) 00:29:31.84ID:P59vPp8D
ここは軽量DDDを議論するところなの?
86デフォルトの名無しさん
2017/11/06(月) 13:22:13.87ID:s60z57bG
>>84
リクエストとレスポンスのインタラクションは
コントローラ
データの「加工」「変換」「検索」「演算」「結合」
ここらへんが絡む物はサービス?
DBMSのコネクションの利用はモデルじゃなくてサービスかな
モデルはただ単に「属性」を持っているだけでいい。
それと最低限のゲッターとセッター
こんなところだろうか??
バリデーションや業務ルールのチェックはモデル??サービス??
87デフォルトの名無しさん
2017/11/06(月) 19:18:41.19ID:9L+ZJ2Xp
考えるな 感じるんだ

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


サービスだとおもいます
88デフォルトの名無しさん
2017/11/10(金) 15:55:49.97ID:WtBM3Wp4
他人が構築したドメイン構造を把握するスキルも
重要なのかな?
日本のSIlerの場合常駐先がしょっちゅう変わったりする
んだからそうなるとドメインを構築しようとか
どんなドメインなのかの把握が面倒になってしまう。
89デフォルトの名無しさん
2017/11/10(金) 21:17:00.97ID:LsbUks3P
>>86
いろんな考え方があるけど一番シンプルなのは
DDDではドメインが一番大事だからドメインと他を切り分けること

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

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

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

たとえばよくある例では日付でうるう年の判定などは
明らかにドメインの知識だからドメイン層に置く
90デフォルトの名無しさん
2017/11/12(日) 10:23:37.61ID:j0JK3XOe
バリデーションはエラーメッセージ、UIの強調表示なども絡むからどう考えたってプレゼンテーション層でしょ
ビューモデル(プレゼンテーションの都合であるモノ)のプロパティ属性にバリデーションルールを書くことが標準的になっている点からもこの事実は明らか
91デフォルトの名無しさん
2017/11/13(月) 07:29:43.51ID:XVC/GNte
>>90
ASP.NETだけどビューにバリデーション書いたとしてjavascriptゴニョゴニョされてバリデーション突破されたら怖いからコントローラにもチェック入れてる
設計的に正しいのかは解らない
92デフォルトの名無しさん
2017/11/13(月) 08:20:06.77ID:1kxbOfqW
>>91
>>90とやってること一緒じゃね?
93デフォルトの名無しさん
2017/11/13(月) 08:41:32.54ID:vmC6RyQT
目的が違えば両方あってもいいんじゃね?ユーザーの利便のためか自衛のためか。
94デフォルトの名無しさん
2017/11/13(月) 09:17:00.78ID:KJNT45pE
>>91
ASP.NETって、ビューモデルのバリデーションをクライアント側のJSで突破できちゃうの?
95デフォルトの名無しさん
2017/11/13(月) 12:08:35.87ID:1LsyXLAY
ジャバオのバリデータだろ
96デフォルトの名無しさん
2017/11/13(月) 18:48:33.23ID:1kxbOfqW
>>94
そう書いたらそうなる
普通はControllerでチェックする
97デフォルトの名無しさん
2017/11/13(月) 20:17:19.09ID:IDSFIQtw
>>90
クライアントのJSで検証したらサーバー側のコントローラで検証しなくても良いと?
んなわけねーだろ普通両方やるわ
98デフォルトの名無しさん
2017/11/13(月) 22:06:30.64ID:KJNT45pE
プレゼンテーション層でチェック
クライアントでチェックする

一緒にしてる奴がいるね
ちなみにコントローラーもプレゼンテーション層な
99デフォルトの名無しさん
2017/11/14(火) 05:47:03.90ID:9Gbq8NEA
>>98
>>97
https://blogs.msdn.microsoft.com/nakama/2009/09/28/293/
で触れてるような信頼境界の話だろ
100デフォルトの名無しさん
2017/11/14(火) 07:18:29.77ID:R9xQaEyZ
>>98
Controlerってアプリケーション層じゃ無いんだ
出典無いから自信無いけど
101デフォルトの名無しさん
2017/11/14(火) 19:38:43.49ID:kwaLWx7P
セキュリティとか悪意のある攻撃を想定すると
話が厄介になるね
セキュリティ考慮でなければ、情報の源泉に近い
JSでバリデーション1本だけで十分だろう。
セキュリティとか認証が絡むとこういったレイヤの層分け
が狂う要因になるのだろうか?
102デフォルトの名無しさん
2017/11/15(水) 03:47:42.79ID:3vTQ1KLC
>>101
仕事で使うなら想定しないケースも希だと思うけど
103デフォルトの名無しさん
2017/11/16(木) 07:24:52.29ID:yg2PUXdS
DIのフレームワークとDDDって共存できるの

DDDってMVCみたいなレイヤードアーキテクチャからドメイン抜き出したもの程度しか認識ない人間だけど
104デフォルトの名無しさん
2017/11/16(木) 07:30:52.62ID:DVV+REXJ
>>103
MVCはレイヤードアーキテクチャじゃないよ
105デフォルトの名無しさん
2017/11/16(木) 12:33:04.40ID:i9LdlFRo
>>104
モデルビューコントローラはレイヤじゃ無いのか
そう言えばモデル層とか聞かないね
106デフォルトの名無しさん
2017/11/17(金) 08:39:38.18ID:jlfmLuFK
validationとormがDDDのボトルネック
要するに机上の空論
107デフォルトの名無しさん
2017/11/17(金) 23:50:35.86ID:tGAvpZAK
UIの要求が強すぎるとうまくいかんのだわ
ドメインクラスをフロントとバックの両方に書くはめになる
Node.jsだとそのへんうまくいくのかな
108デフォルトの名無しさん
2017/11/18(土) 13:44:21.91ID:VuzSnHPO
お前ら設計書ってどうしてる?
仕事でやる以上は設計書出せと言われたら書かなきゃならない
設計書がレビュー通らなきゃコーディングは始められない
バリューオブジェクトの設計書とかあまりにも馬鹿馬鹿しいんだけど何百個も書かなければならない
109デフォルトの名無しさん
2017/11/18(土) 15:21:12.87ID:2Obhafep
>>108
なんて言ってほしいのかわからない
仕事なんだからやれって言われたらヤるしないって立場なんでしょ?
じゃあやるしかないじゃん

バリューオブジェクト数百個っていったらそれなりの規模のシステムだろうから
バリューオブジェクトを使わなかったとしてもどうせ大量の設計書を書かないといけないし、
今となってはそういう仕事を受けたのを悔やむことぐらいしかできないのでは?
110デフォルトの名無しさん
2017/11/18(土) 15:39:25.13ID:5iID0bAm
しかも設計書がExcel方眼紙なんだよな。
111デフォルトの名無しさん
2017/11/18(土) 15:47:54.83ID:drMX1Uce
設計書なんで実装終わったときに揃ってれば良いだろ
どうせ開発中にコロコロ仕様変わるなんてよくある話だ
112デフォルトの名無しさん
2017/11/18(土) 16:01:31.09ID:yU1kJYiv
レビューがあるから先に設計書を書かないとダメ
でも設計書で設計するとグダグダになる
設計書から目をそらす以外にうまくいく方法があるなら教えてくれ
113デフォルトの名無しさん
2017/11/19(日) 08:43:56.41ID:9uDeEGku
テキトーに書いておく
レビューする側に解ってる人がいるのは稀だからタイテーはこれで何とかなる
114デフォルトの名無しさん
2017/11/19(日) 11:30:11.10ID:CpArH3Dx
先にユニットテスト済みのコードを書く
doxygenで設計書生成
レビューしてOKを貰う
コーディングしてるふりして1日サボる
コードをプッシュ
115デフォルトの名無しさん
2017/11/19(日) 12:43:48.77ID:+HG5lDnd
>>114
doxygenってExcel方眼紙出せたっけ?
116デフォルトの名無しさん
2017/11/19(日) 13:09:42.41ID:CpArH3Dx
エクセル設計書なんて使わない
117デフォルトの名無しさん
2017/11/19(日) 13:56:40.03ID:+HG5lDnd
>>116
使いたかないけどさ。
たぶん >>108 にそんな自由はない。
118デフォルトの名無しさん
2017/11/19(日) 16:15:48.08ID:lEYmgXHF
Excelに貼り付けるテキストを自作ツールで出力。
119デフォルトの名無しさん
2017/11/22(水) 15:13:08.97ID:LuqUsrvZ
ビジネスロジック層と永続化層の違いについて聞きたいんだが
「ビジネスロジック」は「犬」とか「リンゴ」とかいうクラスを作る層で
「永続化層」は「犬テーブルを操作するオブジェクト」を定義するクラス
を作る(というかPDOとかActive Recordとかが用意している)という
認識でいいのか?
120デフォルトの名無しさん
2017/11/22(水) 18:17:46.26ID:Fja20xY7
ざっくり言うとデータベースに関係あるのがインフラ層
121デフォルトの名無しさん
2017/12/05(火) 00:47:41.31ID:dpNb6B9r
エヴァとのコラボカードナナコ最高。http://maeda-gourmet.jp/2016/09/09/nanaco/
122デフォルトの名無しさん
2018/05/23(水) 21:07:55.14ID:Au5e7VGg
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

Q3XKO
123デフォルトの名無しさん
2018/07/05(木) 00:49:06.04ID:RfoszcD2
ZJY
124デフォルトの名無しさん
2018/09/09(日) 06:43:58.22ID:HEZvkUhE
ゲーム開発でDDDは使えますか?
その場合のドメインとドメインエキスパートとは例えば何、誰を指すでしょうか?
125デフォルトの名無しさん
2018/10/08(月) 00:49:59.53ID:Kbmtp0Cm
ボトムアップドメイン駆動設計
https://ddd-community-jp.connpass.com/event/103428/

ぜひ参加してください!
126デフォルトの名無しさん
2018/10/11(木) 20:53:29.46ID:f3Pn3eWA
Eric Evans氏はドメイン駆動設計(DDD) は未完成だと述べた
https://www.infoq.com/jp/news/2018/10/ddd-not-done
127デフォルトの名無しさん
2018/10/24(水) 09:23:12.56ID:HQt07idp
>>125
講師がひとりで勝手に盛り上がってて寒いセミナーだったな
マーケ視点で物事を考えない典型的駄目エンジニアって感じだから内容も薄い薄い
128デフォルトの名無しさん
2018/10/25(木) 01:29:02.78ID:c44lxtY/
こんなやつらがDDDやってるんだなってのがわかって結構面白かったけどね
今日の内容で本書きます!って言われたときはさすがに周り失笑してたけど
129デフォルトの名無しさん
2019/03/17(日) 12:58:39.06ID:F89k9A+v
まだ、軽量DDDなんかやっている人がいるのね。
130デフォルトの名無しさん
2019/04/25(木) 08:19:51.47ID:NTtreDXN
意外と盛り上がらないね。
131デフォルトの名無しさん
2019/04/25(木) 20:00:13.26ID:NTtreDXN
ドメインが複雑じゃないとあんまり意味なさそうなのは感じ無くもないけど、将来の改修のしやすさのための布石と思えばいいのかな。
132デフォルトの名無しさん
2019/05/06(月) 12:07:22.28ID:y1ayn2s5
>>131
 ドメインモデルが有効に機能するのって、イラレ、フォトショ、動画編集、オフィス系のようなパッケージアプリぐらいだと思う。

 普通のDB叩くアプリではいらないと思う。
133デフォルトの名無しさん
2019/06/20(木) 07:02:35.15ID:o5P3FSwL
業務系はエンティティ間の関連が多すぎてリポジトリパターンと相性が悪いと思う
トランザクション分析すると集約ルートが複数のテーブル全体を巻き込んだりする
134デフォルトの名無しさん
2019/10/11(金) 20:14:12.01ID:hGbwA5Kq
最近DDDの本読んで勉強してるが、日本じゃ流行らなさそうだなという印象
英語圏なら確かにユビキタス言語からコードにシームレスに移れ、
コードがそのままドメインエキスパートにも読めるドキュメントにできるだろうが…
135デフォルトの名無しさん
2019/10/12(土) 06:32:18.26ID:RANQu5YO
古典的なデータモデリングのマッピング先がOOPに変わっただけという印象なんだけど。
136デフォルトの名無しさん
2019/10/12(土) 14:21:09.70ID:7TGqmTiW
>>135
DDD本で紹介されてる概念やテクニックはOOPに限られたものじゃないよ
DOAの古典的データモデリングでも十分に役立つし関数型のパラダイムで実装することもできる

日本語でDDDについて書かれてる記事は質が低いのが多いから
ちゃんと理解したければEric Evansの原典かVernonの"Domain-Driven Design Distilled"を読むのを勧める
137デフォルトの名無しさん
2019/11/27(水) 21:15:02.91ID:ymKEnJ4Y
「Hands-On Domain-Driven Design with .NET Core」Alexey Zimarev

これ結構いい本
Packtのサイトでセール中なのか今なら10$で買える
138デフォルトの名無しさん
2019/12/22(日) 03:38:09.90ID:n6weJVCQ
>> 128
これ?
https://www.shoeisha.co.jp/book/detail/9784798150727
目次見るとなんだかなと思う。
139デフォルトの名無しさん
2020/02/08(土) 08:56:40.52ID:YyWxF9Co
モデル層とデータストア層って分離できないのかな。

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

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

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

考えてばかりでプログラミングを開始できない。。。
140デフォルトの名無しさん
2020/02/08(土) 09:03:45.09ID:YyWxF9Co
pythonでもドメイン駆動設計するのに問題ない?
141140
2020/02/08(土) 09:04:48.14ID:YyWxF9Co
>>140
PythonのDjangoでWEBアプリを考えています。
142デフォルトの名無しさん
2020/02/08(土) 12:58:17.20ID:0wE1WgKD
>>139
Django ORMはActive Record PatternだからDBが先にあるような場合にはうまくいかない
そもそもActive Record使ってるとモデルとデータストアの結合度が高い
分離したければRepository Patternを自分で実装するかそれをサポートしてるフレームワークを選択するか

“python repository pattern”で検索
143139
2020/02/09(日) 12:24:41.03ID:dmd9x03B
>>142
レスありがとうございました。

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

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

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

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

モデルが何か中間層のオブジェクトを経由してデータテーブルに保存できるようにすれば、
モデルの変更はモデルの変更に終止させられるかもしれません。
144デフォルトの名無しさん
2020/02/09(日) 20:14:19.34ID:R6dJMwaP
>>143
>モデルが何か中間層のオブジェクトを
それがリポジトリと呼ばれるもの
145デフォルトの名無しさん
2020/02/10(月) 00:10:18.78ID:0IUSwyg5
>>144
なるほど。

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

それにしても、モデルの変更は中間層の対応クラスやデータテーブルにも及んでしまうなあ。
146デフォルトの名無しさん
2020/02/10(月) 20:33:59.96ID:EqwKVKI1
モデルが中心で一番重要だから当たり前
データベースやフレームワークの都合でモデルが振り回される方が厄介

というか安定性が一番高く変化しにくいのがモデルのはずで、先にきちんと分析してある程度要件を固めないといけない
147デフォルトの名無しさん
2020/02/11(火) 10:44:43.50ID:qbg35N4F
>>146
モデル中心で設計していきたいと思います。

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

モデル(∞)-テーブル(1)のような関係になりそうです。
それを結合させられる中間層(リポジトリ?)を自分で考えたいと思います。
148デフォルトの名無しさん
2020/02/11(火) 12:30:25.83ID:rXVtelf6
リポジトリで重要なのはインターフェースと実装を分けること
インターフェースはモデル層になるけど、実装はモデル層にはなくデータベース関連の知識は実装に閉じ込める
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.66ID:v/oRLdRM
>>147
>テーブル上にまたがった(リレーションされた)データを、
>どうモデルに切り分けると良いか考えたいと思います。

それはモデル中心じゃなく既存テーブル中心設計じゃないか?
150デフォルトの名無しさん
2020/02/11(火) 19:36:41.89ID:Vv3Ln0ZS
とはいえ普通の開発は既存のDBのテーブルに引きづられるのが実際だろ。
151デフォルトの名無しさん
2020/02/11(火) 21:46:53.70ID:v/oRLdRM
>>150
DDDのようなモデル中心の設計では
ビジネス要求だったりユースケースだったり
アプリケーションの外部仕様を満たすために最適なドメインモデル考えるのが先

既存DB構造を含めてそのモデルをどう永続化するかはそれよりも後
もちろん既存DBの構造によってドメインモデルを変更せざるを得ない場合もあるが
>>147が書いてるとは考え方の主従が違う
152デフォルトの名無しさん
2020/02/13(木) 00:19:28.03ID:slfRt6Hj
GoとかRustとかのクラスベースじゃないのとJavaとかのクラスベースってどっちがDDDしやすいの?
ライブラリ、フレームワークとかの資産とかなしにして
153デフォルトの名無しさん
2020/02/13(木) 02:16:39.59ID:zqMi9kcN
>>148
詳細なレスありがとうございます。

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

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

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

本当はOSS界のPythonに憧れてはいたんですけどね。
154デフォルトの名無しさん
2020/02/13(木) 02:20:34.42ID:zqMi9kcN
>>149-151
たしかに、
自分が求めに応じて何を作りたいのかが先に立ちますよね。
すると、モデルが先に来る。

しかし、既に構築済みシステムのデータベーステーブルの存在もあるので、
あくまで、モデル中心にして必要なデータを既存テーブルから拾ってくるというような考え方にしておきます。
その意味では、既存データベースに無い物はモデルとして成立させられないわけですが。
155デフォルトの名無しさん
2020/02/13(木) 15:23:21.01ID:6VutC31N
53 恋する名無しさん
2018/12/15(土) 21:15:59.13 ID:Ai0sRA6M0

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

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

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

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

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

兵庫県教育委員会は小宇根放火ストーカーに燃やされ全焼兵庫県教育委員会全員火の海俊興ストーカーに燃やされ小宇根放火焼殺魔精神異常家系
156デフォルトの名無しさん
2020/02/13(木) 18:03:52.96ID:r7bSHOfr
>>152
クラスベースかどうかの違いはあまり関係ないんじゃないかな
ドメインモデルをコードに落としやすいかどうかは型の表現力によると思う

Sum Typeを作りやすいかどうかや
value object用のimmutableオブジェクトを作りやすいかどうかみたいな部分
RustやSwiftのenumだったりKotlinのdata classみたいなやつ
157デフォルトの名無しさん
2020/02/16(日) 13:43:23.03ID:Xiaae5hS
ドメインモデル的にDBは検索可能なファイルフォーマットみたいな考え。
PDFやPSDファイルを考えるとわかりやすい。ファイルから読み出すとドメインモデルになる。
158デフォルトの名無しさん
2020/02/18(火) 21:40:17.43ID:2AC9Ct1n
それだとormはどういう位置付けになるん?
159デフォルトの名無しさん
2020/02/19(水) 00:06:44.71ID:i9qIzFMe
>>158
Repositoryじゃね?
160デフォルトの名無しさん
2020/02/19(水) 00:14:21.11ID:pJACNDga
性能で行き詰まった時に普通に破綻しそうなんだが。
161デフォルトの名無しさん
2020/02/19(水) 01:31:27.23ID:i9qIzFMe
性能で行き詰まったら、金の弾丸ブチ込めってばっちゃが言ってた
162デフォルトの名無しさん
2020/02/20(木) 22:05:54.44ID:ABNkvVkH
未だにファクトリーだけメリットがわかりません
newとなにが違うんですか?
163デフォルトの名無しさん
2020/02/20(木) 23:00:47.67ID:Nllb9nDe
>>162
引数によって継承したクラスを選択して返す様に設計できる。
164デフォルトの名無しさん
2020/03/05(木) 22:14:17.50ID:h922Dn8C
>>152
オブジェクト指向言語の方が
DDDに基本的に向いていると思う

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

JavaやC#
RubyやPythonも
165デフォルトの名無しさん
2020/03/05(木) 22:20:29.48ID:h922Dn8C
>>162
DDDというかデザインパターンの話だけど
ファクトリ(系パターン)を使うのは
インスタンスの生成が複雑な時

たとえばAとBのインスタンスを常にペアで使いたいとか
いろんな条件でnewする部分が肥大化していくようなら
毎回書くよりファクトリパターン使う方がスマートでしょ?
166デフォルトの名無しさん
2020/03/08(日) 23:30:12.89ID:4J5clray
そうかなあ…一番DDDやりやすいのは関数型言語だと思う

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

また純粋なビジネスロジックは作用のない関数によって表現され、
ビジネスロジック以外の部分が作用を持つ関数になるはずで、
作用のある無しを型レベルで区別する純粋関数型言語であれば、
その辺の層分けもすごく自然 むしろ別れざるをえない
167デフォルトの名無しさん
2020/03/08(日) 23:55:07.82ID:2h+/wurX
作用?
168デフォルトの名無しさん
2020/03/09(月) 21:19:31.81ID:bHKN7jy6
左様でござる
169デフォルトの名無しさん
2020/03/09(月) 22:12:07.02ID:ajCpPJPb
Webみたいにステートレスで済むなら
関数型の方が簡潔に書ける部分もあるが

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

FPでもDDDはできるが
OOの方が向くことが多い
170デフォルトの名無しさん
2020/03/09(月) 22:18:06.74ID:aVP5r6mu
階層構造を持ってるからOOの方が向いてるってのはよくわからないな
171デフォルトの名無しさん
2020/03/09(月) 23:12:50.10ID:y1num/wG
?複雑な状態遷移があるとFPが向かないっていうのもよくわからないな
状態の数だけ型作って、遷移の数だけ関数つくればいいだけやん

OOPはむやみにクラス内に隠れた状態や依存を作って他のクラスとうまく合成されない物を作りがち
そんなことしてると、非同期な処理を並列化とかしようにも気にしないといけないことが増えて大変な労力だろうに
172デフォルトの名無しさん
2020/03/14(土) 17:55:44.71ID:JKHuUiBu
>>171
言いたいことはわかるが、websocketみたいなコネクション管理するものを
まるまる関数型で書くなら状態変化を含んだとしてもオブジェクト的に記述した方が
多分楽。
なんでもどっちかに倒そうとすること自体が悪パターンな気がするよ。
173デフォルトの名無しさん
2020/03/14(土) 18:05:14.78ID:ZFQFhT9Y
良いとこ取りしていけ
174デフォルトの名無しさん
2020/03/15(日) 00:23:36.09ID:UpO1XTWv
>>172
WebSocketかー。やったことないからやってみよう
175169
2020/03/15(日) 05:56:57.78ID:1/DFOu+E
>>170
継承や委譲で階層構造を表現できる

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


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

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

ただ非同期で並列化が必要な場合とか
ミッションクリティカルな場合で
バグを極力出したくない場合は別の話
176デフォルトの名無しさん
2020/03/15(日) 08:25:11.78ID:j83nFY2E
>>175
あんたに限らず関数型が大規模なプログラム書くのに向かないと思ってる層がちゃんと関数型プログラミングをしたことがなく先入観でもの言ってるのはよくわかった
177デフォルトの名無しさん
2020/03/15(日) 08:38:54.73ID:1/DFOu+E
>>176
あんたも決めつけで言ってるだけだろ
関数型で状態遷移を把握しづらいのは
強く実感しているし普及しない原因だ
178デフォルトの名無しさん
2020/03/15(日) 09:21:24.78ID:UpO1XTWv
>>177
それはどの言語でどんなことしようとして「強く実感」したの?

関数型言語が普及しないのは、単に先入観やOOP神話の影響で学ぼう使おうと思う人が少ないからだよ。
関数型プログラミングが普及しない理由は、当然だが関数型プログラミングの諸概念を表現するのに命令型言語が不向きだから。柔道着着て水泳するようなもんだ。
179デフォルトの名無しさん
2020/03/15(日) 14:50:21.29ID:7lggs81n
>>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.77ID:XbDoNvCk
一昔前のOOP厨と一緒だな。
歴史を学ばん奴は一生ループする。
181デフォルトの名無しさん
2020/03/15(日) 23:47:43.93ID:zobMuC0O
>>179 そうだよなと得心する事が多くて良い資料ですね
ドメインに継承や移譲が要るって考えてる人は是非とも読んで欲しいし、反例を挙げて欲しくなる
182デフォルトの名無しさん
2020/03/16(月) 00:15:47.56ID:PIKXUqlC
>>179
俺もこのスライドの作成者の本で関数型DDDに入門したクチだけど、本当にわかりやすかった
もともとHaskell, purescriptはやってて関数型には慣れてたけど、
DDDについては知らなかったので、せっかくだから関数型前提で書かれている本でと手にした。
Domain modeling made functional っていう本で、
DDDの解説はもちろん、関数型プログラミングの諸概念の解説もわかりやすく、
一冊で二度美味しい内容で、実用的な関数型プログラミングの入門書としても超おすすめ。



ちなみにyoutubeにはこのスライドの発表動画もあったりする
183デフォルトの名無しさん
2020/09/16(水) 23:15:57.30ID:hC0if/qX
Matthias Felleisenの「How to Design Programs」を読んで関数型プログラミングに
興味を持ったものです。
次にモナドを勉強しようとしてHaskellの本を読んだがいまいちピンときません。
>>182さんが挙げられている本では、モナドを使ってモデルの実装をしているようですが、
モナドの使い方は理解できますか?
184デフォルトの名無しさん
2020/09/17(木) 01:01:40.98ID:m/PpcUvw
Scalaで良ければ、manning.comからでてる Functional and Reactive Domain Modeling にモナドでドメインサービス組み立てる話が掲載されてる。
なおFree Monadをベースとしているので軽く死ねる。

https://www.manning.com/books/functional-and-reactive-domain-modeling
185183
2020/09/17(木) 23:32:13.91ID:pIiN+iyt
>>184
ありがとうございます・・・でもDomain modeling made functional をPDFでポチっちゃいました。
後で読もうと思います。
ところでDDDを学ぶ上で、大規模な開発経験が必要なんでしょうか?
自分は学生で、そのような経験がありません。
『How to Design Programs』では小さなプログラム作成の演習はありましたが、
それ以上の大きさのプログラム作成の方法はありませんでした。
DDDは大きなプログラムをつくるガイドになりますか?
186デフォルトの名無しさん
2020/09/22(火) 23:49:46.08ID:mxGu0eGU
>>184
これ
187デフォルトの名無しさん
2020/09/23(水) 00:07:54.77ID:NN2kaL4Y
>>184
これ読んでみようかと思ったら

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

とあるんだが、読むのにドメイン駆動設計の深ーい知識は必要だった?
188デフォルトの名無しさん
2020/09/23(水) 06:16:40.99ID:VKAwJeUe
DDD興味ある
大いに語るがよい
189デフォルトの名無しさん
2020/09/23(水) 07:12:30.61ID:SbRHy3fQ
>>187
必要最小限ではあるがScalaの文法解説と、各ドメインオブジェクトの解説は入っていたはず。
知っていれば理解が進みやすいくらいに考えてればいいはず。
190デフォルトの名無しさん
2020/09/23(水) 19:36:49.05ID:4eJQ0d8P
>>189
thx
191デフォルトの名無しさん
2020/09/30(水) 19:59:30.09ID:0r1wHLnO
DDDもそろそろバージョンアップせんと
OOPは時代遅れ
192デフォルトの名無しさん
2020/12/02(水) 20:38:28.14ID:E6FeESB6
Freeモナドなんて言語埋め込みDSLを作るってだけ
193デフォルトの名無しさん
2020/12/05(土) 00:03:20.35ID:FFFEgOY+
DDDいいよね!
なんちゃってOOPから脱出する際に役立ったよ
194デフォルトの名無しさん
2021/03/31(水) 07:17:34.67ID:PqSCUqXE
DDD、CQRS、イベントソーシング…
企業内システムでここまでやってるとこってあるんだろうか
参照系中心のシステムでDDDやるのは愚行?
195デフォルトの名無しさん
2021/05/18(火) 06:36:21.05ID:Z0RWJbQc
おれはさとった

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

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

それがDDD
196デフォルトの名無しさん
2021/05/19(水) 20:38:26.97ID:NeVz061v
それだけでDDDは語れないような…
いまだに集約がわからんよ
197デフォルトの名無しさん
2021/05/23(日) 21:05:34.48ID:hHIInayx
教科書が概念的でよくわからんことばっかほざいてる時点でおかしい
サンプルを一発提示すればああこんなのねって
それで終わるだろ!?
198デフォルトの名無しさん
2021/07/13(火) 00:57:28.25ID:FnRTq1rf
ガサッと取ってきて変更して全部更新!ってアホなんって思った
これの何がいいの?
199デフォルトの名無しさん
2021/07/13(火) 22:24:26.83ID:fj1E0qkc
CRUD で十分な単純なアプリならいらない
200デフォルトの名無しさん
2021/07/14(水) 08:14:14.87ID:wgyTk/up
>>197
2003年頃ならともかく。OSSのアプリが溢れている今の状況ならこのアプリのこの部分はこのパターンを使っているって示せると思う。
201デフォルトの名無しさん
2021/08/10(火) 20:46:36.95ID:R7L3+gXm
>>191
亀レスだが、OOPを補完するのがDDDだろうに
なんでDDDスレでOOPが時代遅れだと言えるのか疑問
202デフォルトの名無しさん
2021/08/10(火) 23:57:50.00ID:yd00h36W
>>201
OOPより上位レイヤーの概念なのでOOPを補完するものではないよ
Eric Evansの最初の本ではDDDの実装例としてOOPが使われただけ
関数型で実装する例もある
203デフォルトの名無しさん
2021/08/11(水) 22:58:43.10ID:AUz9CV9O
>>202
> OOPより上位レイヤーの概念なので
> Eric Evansの最初の本ではDDDの実装例としてOOPが使われた

そういうのを補完って言うのでは?
204デフォルトの名無しさん
2021/08/12(木) 23:34:58.79ID:1njm/kBk
>>203
お前は国語から勉強し直さないとこの先辛いぞ?
お前は概念とか言ってる場合じゃない
205デフォルトの名無しさん
2021/08/13(金) 08:38:17.53ID:yFah4eQP
ほかん
【補完】
《名・ス他》
足りない点を補って完全にすること。

OOPに足りない部分をDDDで補ってるって言いたかったのでは?
別に変だとは思えないけど
206デフォルトの名無しさん
2021/08/13(金) 09:30:37.30ID:4chv34Gy
OOPを補完するのがプログラミングだろうに
なんでプログラミングスレでOOPが時代遅れだと言えるのか疑問

OOPに足りない部分をプログラミングで補ってるって言いたかったのでは?
207デフォルトの名無しさん
2021/08/13(金) 11:25:44.59ID:klCtaRRF
OOPはプログラミングを補うものでありプログラミングがOOPを補う訳ではない
208デフォルトの名無しさん
2021/08/13(金) 11:56:11.61ID:VPbn/mvQ
>>205
補完などではない
そもそもOOPなどと書くから話がおかしくなる

DDDはOODを包含した概念である
209デフォルトの名無しさん
2021/08/13(金) 13:49:07.82ID:iLxHQIIJ
OODと言い換えたところで補完もしてなければ包含もしてない

DDDをOOの文脈でしか理解できない人は抽象概念の理解がもともと不得意なのか
日本人の書いたなんちゃってDDD本で分かったつもりになってるか
そもそもOO以外を知らないか
210デフォルトの名無しさん
2021/08/13(金) 14:28:21.12ID:klCtaRRF
お前はDDDを学んでもOOP及びOODには何の影響もないみたいだけど、俺は別にDDDで学んだ知識がOOP/OODに役立ってるので、別にどうでもいいっす。
なんで役立ったのか想像できないのなら、その程度ってことでしょう。
211デフォルトの名無しさん
2021/08/13(金) 15:21:02.98ID:cdK9y9f/
ブホッw
212デフォルトの名無しさん
2021/08/14(土) 07:58:11.46ID:3YTtOTVG
OOPにありがちな、車やエンジンを例にした説明より
DDDの方がしっくりくるというか
あ、OOPでこんなことができるのかと目から鱗だったな
213デフォルトの名無しさん
2021/08/14(土) 15:27:00.83ID:db9EEEoY
いつの時代になってもITの方法論は「方法論オナニストに都合のよい飯の種」の域を出ない
214デフォルトの名無しさん
2021/08/14(土) 15:31:45.91ID:4CNv29yk
建設業のように国が規格を決めてしまえばよかったんだ
国所属の認定団体に承認された関数以外使ってはいけません
215デフォルトの名無しさん
2021/09/16(木) 15:51:11.37ID:PMPdG/+a
DDDとは、「ドメイン知識(モデル)」を「駆動」して「開発」する開発手法であって、何か特定のアーキテクチャをあらわすものではない
216デフォルトの名無しさん
2021/09/16(木) 15:54:48.85ID:PMPdG/+a
嘘言いました
最後のDはDevelopmentじゃなくてDesignだったわ
恥ずかしー
217デフォルトの名無しさん
2021/09/16(木) 19:58:10.14ID:d3wmnSJn
もーやだー
218デフォルトの名無しさん
2021/09/26(日) 11:30:18.78ID:0AJzxi3v
設計はアーキテクチャを示すものじゃない
言葉が違えば意味が違う
219デフォルトの名無しさん
2022/05/07(土) 06:20:48.85ID:Japg54lQ
DDDは大量データ更新に弱い
10万件のレコードに同じ値をセットする処理に途方もなく時間がかかる
220デフォルトの名無しさん
2022/07/27(水) 17:37:37.82ID:hi2YYXJ0
カルト宗教だよね
設計というのはパフォーマンス要件の整理と実現に当たってのアーキテクチャを考えるために必要なわけで
機能要件にSLAがないだなんてことは設計するならばありえないし、
じゃあその要件に到達するためにシステムやミドルウェアをどう使っていくかがアーキテクトの肝なところじゃん
APPサーバに閉じた議論しかしてない時点で雑魚システムしか作れんし
雑魚システムにそもそも設計なんざいらんだろって話よ

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

それでDBがやってくれてるトランザクション制御や成約、整合性の解決を
ファイルシステムで実装するその実装を誰が書くの?
アーキテクトを自称するなら君が書くってことだけど、いったい誰がそんなこと頼んだんだろう
221デフォルトの名無しさん
2022/07/27(水) 17:39:26.99ID:hi2YYXJ0
型システムの理解も貧弱、DBMSの理解も貧弱、なんならネットワーク・プロトコルの理解も貧弱

一生システム完成させる気ないやる気なしエンジニアの最後の拠り所だろ
222デフォルトの名無しさん
2022/07/27(水) 20:57:03.92ID:i1UDtnj5
だいぶ詳しい反論だなw
223デフォルトの名無しさん
2022/07/27(水) 21:51:14.18ID:gDp6GlMI
https://enterprisecraftsmanship.com/posts/ddd-bulk-operations/
DDDでバルク処理
そこまで拘らなくていいんじゃないかなと言う感想
224デフォルトの名無しさん
2023/09/22(金) 05:22:44.35ID:dV2V1da1
これってどうやって気にするの?
225デフォルトの名無しさん
2023/09/28(木) 03:45:15.07ID:i8VmgZE9
ゴシゴシ(-_\)(/_-)三( ゚Д゚) ス、スゲー!
226デフォルトの名無しさん
2023/12/03(日) 23:52:03.41ID:p5/cY/Es
テスト
227デフォルトの名無しさん
2024/12/06(金) 22:29:28.26ID:IVgCNi6x
関数型DDDの本の作者のアーキテクチャが話題になっている
Repositoryはいらない
大事なのはIOをロジックの中から排除せよということらしい
以下のように"端に寄せる"

IO
ビジネスロジック
IO

目から鱗だった
IOへの依存をなくすことでテストしやすくなるしモックもいらない
228デフォルトの名無しさん
2024/12/07(土) 18:42:46.99ID:cdxtdz0L
ビジネスロジックはパイプラインで構築して副作用がないようにする
229デフォルトの名無しさん
2024/12/08(日) 00:14:30.46ID:fPMU02oZ
DDDは素晴らしいと思うけど、プロジェクト内の他エンジニアのスキルが低いとアンチパターンになるんだよな
230デフォルトの名無しさん
2024/12/08(日) 14:38:22.52ID:5KF429T4
DDDって再現性ないじゃんw
偽科学
231デフォルトの名無しさん
2024/12/08(日) 15:54:58.48ID:yVSjHkLG
設計に再現性はないよ
要件が全く同じということがないから
だから難しい
232デフォルトの名無しさん
2024/12/08(日) 15:56:35.36ID:yVSjHkLG
IOを"端に寄せて"ビジネスロジックはパイプラインで実行して不変データ構造にするというアイデアマジで凄い
これからこの設計にする
233デフォルトの名無しさん
2024/12/08(日) 19:27:00.60ID:xllqP0wk
そのぶんリソースバカ食いのクソアプリの出来上がり
234デフォルトの名無しさん
2024/12/09(月) 00:32:52.38ID:+1IlmX9/
根っこに流れる考えは、コマンドラインシェルでコマンドをパイプで繋いでいくことと同じだけどね。

一連のワークフローを一つのコマンドとみなして、さらに大きなワークフローに組み込むところとかもね。
235デフォルトの名無しさん
2024/12/19(木) 14:37:51.32ID:fGxiJNMh
F#で遊んだ時シェルのパイプじゃんとは思ってた
関数型言語の原点てシェルスクリプトなんか?
236デフォルトの名無しさん
2024/12/20(金) 12:36:38.38ID:xSkBLBiw
>>233
そこで遅延評価ですよ
237デフォルトの名無しさん
2024/12/20(金) 13:57:42.11ID:UU1VM3lj
>>236
やってから言え
遅延評価こそリソースバカ食いだ
238デフォルトの名無しさん
2024/12/20(金) 18:04:51.42ID:eZ4ILWvg
>>237
今の時代リソースなど死ぬほどあるのだよ
自作でサーバー組み立てる場合でもメモリ64Gなんて普通だし
239デフォルトの名無しさん
2024/12/20(金) 18:26:08.17ID:zuM8e09I
>>238
それはお前の作ってるものがしょぼいからだよ
240デフォルトの名無しさん
2024/12/20(金) 18:34:22.69ID:zuM8e09I
クラウドはリソース使えば使うだけ課金
241デフォルトの名無しさん
2024/12/20(金) 19:25:56.31ID:Sq/wbvsq
遅延評価がリソース食うっていつの時代よ?
むしろ今は遅延評価しないとリソースをバカ喰いする時代だぞ
キャッシュと勘違いしてない?
ディープラーニングとか全部遅延評価だ
それこそ>>239の作ってるものがしょぼいという証明になったな
242デフォルトの名無しさん
2024/12/20(金) 19:31:24.56ID:eZ4ILWvg
>>241
多分Haskellの遅延評価のことを言ってるのでは?
メモリをドカ食いすると聞いたことがある
しかしそれは言語のインプリメンテーションやデータ構造の問題であり
一般的な遅延評価がメモリをくうわけではないのよな
243デフォルトの名無しさん
2024/12/20(金) 20:48:35.33ID:zuM8e09I
>>241
だからやってから言えって
Haskellの不評のひとつが遅延評価だ
244デフォルトの名無しさん
2024/12/20(金) 21:17:48.55ID:Sq/wbvsq
Haskell使いは大変でちゅね~
245デフォルトの名無しさん
2024/12/20(金) 22:16:28.31ID:L0BexGzI
遅延評価だからリソースバカ喰いするわけじゃないのにね
バカは因果関係がわからないからな
246デフォルトの名無しさん
2024/12/20(金) 22:30:04.43ID:Sq/wbvsq
Haskellしか書いてないんじゃないの?
知らんけど
247デフォルトの名無しさん
2024/12/21(土) 17:16:28.03ID:unOGov3F
ひぐちデブすぎんか?

lud20250611203300
このスレへの固定リンク: http://5chb.net/r/tech/1508841546/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

TOPへ TOPへ  

このエントリをはてなブックマークに追加現在登録者数177 ブックマークへ


全掲示板一覧 この掲示板へ 人気スレ | Youtube 動画 >50 >100 >200 >300 >500 >1000枚 新着画像

 ↓「【DDD】ドメイン駆動設計【エリック・エヴァンス】 YouTube動画>1本 」を見た人も見ています:
交流会

.
E


愚痴
n
7
虎専
t

んほ

t
珈琲
E
D専
.
n

2
最低
`

んあん

報告

e

A
6
通報部隊
会7

報告
ω

0
~



^



肛門
a
b

)
vv

oo
#2

目薬
阪神
はよ

.
17
ok
AA
22:49:35 up 65 days, 23:48, 0 users, load average: 8.72, 9.06, 9.49

in 0.038143157958984 sec @0.038143157958984@0b7 on 062211