【DDD】ドメイン駆動設計【エリック・エヴァンス】 (247ﾚｽ)
上下前次1-新
1(1): 2017/10/24(火)19:39 ID:jO+jDbIG(1/14) AAS
AA省
121: 2017/12/05(火)00:47 ID:dpNb6B9r(1) AAS
エヴァとのコラボカードナナコ最高。外部ﾘﾝｸ:maeda-gourmet.jp
122: 2018/05/23(水)21:07 ID:Au5e7VGg(1) AAS
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
Q3XKO
123: 2018/07/05(木)00:49 ID:RfoszcD2(1) AAS
ZJY
124: 2018/09/09(日)06:43 ID:HEZvkUhE(1) AAS
ゲーム開発でDDDは使えますか？
その場合のドメインとドメインエキスパートとは例えば何、誰を指すでしょうか？
125(1): 2018/10/08(月)00:49 ID:Kbmtp0Cm(1) AAS
ボトムアップドメイン駆動設計
外部ﾘﾝｸ:ddd-community-jp.connpass.com
ぜひ参加してください！
126: 2018/10/11(木)20:53 ID:f3Pn3eWA(1) AAS
Eric Evans氏はドメイン駆動設計(DDD) は未完成だと述べた
外部ﾘﾝｸ:www.infoq.com
127: 2018/10/24(水)09:23 ID:HQt07idp(1) AAS
>>125
講師がひとりで勝手に盛り上がってて寒いセミナーだったな
マーケ視点で物事を考えない典型的駄目エンジニアって感じだから内容も薄い薄い
128: 2018/10/25(木)01:29 ID:c44lxtY/(1) AAS
こんなやつらがDDDやってるんだなってのがわかって結構面白かったけどね
今日の内容で本書きます！って言われたときはさすがに周り失笑してたけど
129: 2019/03/17(日)12:58 ID:F89k9A+v(1) AAS
まだ、軽量DDDなんかやっている人がいるのね。
130: 2019/04/25(木)08:19 ID:NTtreDXN(1/2) AAS
意外と盛り上がらないね。
131(1): 2019/04/25(木)20:00 ID:NTtreDXN(2/2) AAS
ドメインが複雑じゃないとあんまり意味なさそうなのは感じ無くもないけど、将来の改修のしやすさのための布石と思えばいいのかな。
132: 2019/05/06(月)12:07 ID:y1ayn2s5(1) AAS
>>131
ドメインモデルが有効に機能するのって、イラレ、フォトショ、動画編集、オフィス系のようなパッケージアプリぐらいだと思う。
普通のDB叩くアプリではいらないと思う。
133: 2019/06/20(木)07:02 ID:o5P3FSwL(1) AAS
業務系はエンティティ間の関連が多すぎてリポジトリパターンと相性が悪いと思う
トランザクション分析すると集約ルートが複数のテーブル全体を巻き込んだりする
134: 2019/10/11(金)20:14 ID:hGbwA5Kq(1) AAS
最近DDDの本読んで勉強してるが、日本じゃ流行らなさそうだなという印象
英語圏なら確かにユビキタス言語からコードにシームレスに移れ、
コードがそのままドメインエキスパートにも読めるドキュメントにできるだろうが…
135(1): 2019/10/12(土)06:32 ID:RANQu5YO(1) AAS
古典的なデータモデリングのマッピング先がOOPに変わっただけという印象なんだけど。
136: 2019/10/12(土)14:21 ID:7TGqmTiW(1) AAS
>>135
DDD本で紹介されてる概念やテクニックはOOPに限られたものじゃないよ
DOAの古典的データモデリングでも十分に役立つし関数型のパラダイムで実装することもできる
日本語でDDDについて書かれてる記事は質が低いのが多いから
ちゃんと理解したければEric Evansの原典かVernonの"Domain-Driven Design Distilled"を読むのを勧める
137: 2019/11/27(水)21:15 ID:ymKEnJ4Y(1) AAS
「Hands-On Domain-Driven Design with .NET Core」Alexey Zimarev
これ結構いい本
Packtのサイトでセール中なのか今なら10$で買える
138: 2019/12/22(日)03:38 ID:n6weJVCQ(1) AAS
>> 128
これ？
外部ﾘﾝｸ:www.shoeisha.co.jp
目次見るとなんだかなと思う。
139(2): 2020/02/08(土)08:56 ID:YyWxF9Co(1/3) AAS
モデル層とデータストア層って分離できないのかな。
仕様変更のしやすさからモデル層の独立を図る必要があるけど、
データベースファースト（テーブルが先にあってDBの都合で正規化済み）の場合、
どうやってモデル層とデータストア層を分離できるんだろう。
O/Rマッピングも使えない。
どうやって解決するのが一般的なんだろう。
そもそも、O/Rマッピングが完全にできたとしても、それは初期状態においてであって、
変更を重ねてモデルのフィールドが変更になれば、データテーブルも変更しなければならないはず。
理想ばかりでインピーダンス不整合が脳内で続くんだけど。
考えてばかりでプログラミングを開始できない。。。
140(1): 2020/02/08(土)09:03 ID:YyWxF9Co(2/3) AAS
pythonでもドメイン駆動設計するのに問題ない？
141: 140 2020/02/08(土)09:04 ID:YyWxF9Co(3/3) AAS
>>140
PythonのDjangoでWEBアプリを考えています。
142(1): 2020/02/08(土)12:58 ID:0wE1WgKD(1) AAS
>>139
Django ORMはActive Record PatternだからDBが先にあるような場合にはうまくいかない
そもそもActive Record使ってるとモデルとデータストアの結合度が高い
分離したければRepository Patternを自分で実装するかそれをサポートしてるフレームワークを選択するか
“python repository pattern”で検索
143(1): 139 2020/02/09(日)12:24 ID:dmd9x03B(1) AAS
>>142
レスありがとうございました。
DjangoのActive Record Patternはコードファーストと呼ばれるやつですね。
モデルの変更がデータベーステーブルに直結するので、結合度が高いのがわかります。
最初の開発のしやすさがあっても、変更には弱いのだとわかりました。
python repository pattern について情報が少ないですね。
モデルとデータストアをどう分離できるか考えてみたいと思います。
省2
144(1): 2020/02/09(日)20:14 ID:R6dJMwaP(1) AAS
>>143
>モデルが何か中間層のオブジェクトを
それがリポジトリと呼ばれるもの
145: 2020/02/10(月)00:10 ID:0IUSwyg5(1) AAS
>>144
なるほど。
あるモデルオブジェクトを、中間層にある一対一で対応したクラス食わせると、
データベースの正規化テーブルに適切に分配して、
保存してくれるようなイメージかなあと思っています。
それにしても、モデルの変更は中間層の対応クラスやデータテーブルにも及んでしまうなあ。
146(1): 2020/02/10(月)20:33 ID:EqwKVKI1(1) AAS
モデルが中心で一番重要だから当たり前
データベースやフレームワークの都合でモデルが振り回される方が厄介
というか安定性が一番高く変化しにくいのがモデルのはずで、先にきちんと分析してある程度要件を固めないといけない
147(2): 2020/02/11(火)10:44 ID:qbg35N4F(1) AAS
>>146
モデル中心で設計していきたいと思います。
しかし、データベースが先に立っている旧システムのWEBアプリ化なので、
それらのテーブル上にまたがった（リレーションされた）データを、
どうモデルに切り分けると良いか考えたいと思います。
モデル(∞)-テーブル(1)のような関係になりそうです。
それを結合させられる中間層（リポジトリ？）を自分で考えたいと思います。
148(1): 2020/02/11(火)12:30 ID:rXVtelf6(1) AAS
リポジトリで重要なのはインターフェースと実装を分けること
インターフェースはモデル層になるけど、実装はモデル層にはなくデータベース関連の知識は実装に閉じ込める
python はインターフェースそのものはないみたいだから抽象基底クラスで代用したらどうか
# モデル層はインターフェースのみ定義する
# 使用するデータベースを変更するとか、テストするときはモックに差し替えるとかしやすくなる
from abc import ABC, abstractmethod
class Users(ABC):
@abstractmethod
def save(self, user: User) -> None:
pass
省7
149(1): 2020/02/11(火)13:38 ID:v/oRLdRM(1/2) AAS
>>147
>テーブル上にまたがった（リレーションされた）データを、
>どうモデルに切り分けると良いか考えたいと思います。
それはモデル中心じゃなく既存テーブル中心設計じゃないか？
150(2): 2020/02/11(火)19:36 ID:Vv3Ln0ZS(1) AAS
とはいえ普通の開発は既存のDBのテーブルに引きづられるのが実際だろ。
151(1): 2020/02/11(火)21:46 ID:v/oRLdRM(2/2) AAS
>>150
DDDのようなモデル中心の設計では
ビジネス要求だったりユースケースだったり
アプリケーションの外部仕様を満たすために最適なドメインモデル考えるのが先
既存DB構造を含めてそのモデルをどう永続化するかはそれよりも後
もちろん既存DBの構造によってドメインモデルを変更せざるを得ない場合もあるが
>>147が書いてるとは考え方の主従が違う
152(2): 2020/02/13(木)00:19 ID:slfRt6Hj(1) AAS
GoとかRustとかのクラスベースじゃないのとJavaとかのクラスベースってどっちがDDDしやすいの？
ライブラリ、フレームワークとかの資産とかなしにして
153: 2020/02/13(木)02:16 ID:zqMi9kcN(1/2) AAS
>>148
詳細なレスありがとうございます。
リポジトリの作成について、
インターフェイスと実装を分ける点についてしっかりと考えてみたいと思いました。
なるほど。
インターフェイスをモデルと合わせておくことは重要だと思いました。
少なくとも、データベース層の変更があってもインターフェイスの実装クラスまでで
影響をストップできるのは素晴らしいです。精神的に安心。
ドミノのストッパーみたいな感じがします。
Pythonにはインターフェイスの概念がないというお話を聞いて、
省3
154: 2020/02/13(木)02:20 ID:zqMi9kcN(2/2) AAS
>>149-151
たしかに、
自分が求めに応じて何を作りたいのかが先に立ちますよね。
すると、モデルが先に来る。
しかし、既に構築済みシステムのデータベーステーブルの存在もあるので、
あくまで、モデル中心にして必要なデータを既存テーブルから拾ってくるというような考え方にしておきます。
その意味では、既存データベースに無い物はモデルとして成立させられないわけですが。
155: 2020/02/13(木)15:23 ID:6VutC31N(1) AAS
53 恋する名無しさん
2018/12/15(土) 21:15:59.13 ID:Ai0sRA6M0
人様の家に放火する虫ケラ小宇根信博俊興マンコ顔ヤクザが偉そうなカオして長田高校におるわ
信博の眼球にアイスピック突き刺す
ゲロ小宇根
兵庫県教育委員会兵庫県立長田高校小宇根化学痴漢殺人放火魔仮面教師俊興信博エタ部落未逮捕、
兵庫県警ブラックリスト長田高校殺人教師小宇根信博放火殺人化学教師息子俊興二重人格兵庫県教育委員会小宇根信博長田高校の便所で毎日
うんこブリブリ親父家で俊興に便所占領されてカムリ白車で毎朝長田高校まで朝のウンコしに行く汚な顔仮面視強姦エロアニメ大量購入下三条町2-9
小宇根痴漢変態仮面ムッツリスケベブス汚な顔面放火焼け爛れゴキブリ顔信博殺人犯未逮捕女子高生レイプマニア怖い俊興ストーカー信博化学教師
兵庫県教育委員会長田高校長の家火葬場小宇根放火ストーカー魔に焼殺人された哀れ性暴力反社会人格障害教師にタンマリ給料やりステーキ食べ
省2
156: 2020/02/13(木)18:03 ID:r7bSHOfr(1) AAS
>>152
クラスベースかどうかの違いはあまり関係ないんじゃないかな
ドメインモデルをコードに落としやすいかどうかは型の表現力によると思う
Sum Typeを作りやすいかどうかや
value object用のimmutableオブジェクトを作りやすいかどうかみたいな部分
RustやSwiftのenumだったりKotlinのdata classみたいなやつ
157: 2020/02/16(日)13:43 ID:Xiaae5hS(1) AAS
ドメインモデル的にDBは検索可能なファイルフォーマットみたいな考え。
PDFやPSDファイルを考えるとわかりやすい。ファイルから読み出すとドメインモデルになる。
158(1): 2020/02/18(火)21:40 ID:2AC9Ct1n(1) AAS
それだとormはどういう位置付けになるん？
159: 2020/02/19(水)00:06 ID:i9qIzFMe(1/2) AAS
>>158
Repositoryじゃね？
160: 2020/02/19(水)00:14 ID:pJACNDga(1) AAS
性能で行き詰まった時に普通に破綻しそうなんだが。
161: 2020/02/19(水)01:31 ID:i9qIzFMe(2/2) AAS
性能で行き詰まったら、金の弾丸ブチ込めってばっちゃが言ってた
162(2): 2020/02/20(木)22:05 ID:ABNkvVkH(1) AAS
未だにファクトリーだけメリットがわかりません
newとなにが違うんですか？
163: 2020/02/20(木)23:00 ID:Nllb9nDe(1) AAS
>>162
引数によって継承したクラスを選択して返す様に設計できる。
164: 2020/03/05(木)22:14 ID:h922Dn8C(1/2) AAS
>>152
オブジェクト指向言語の方が
DDDに基本的に向いていると思う
OO以外でももちろん可能だけど
ドメインの表現はOOが一番やりやすい
JavaやC#
RubyやPythonも
165: 2020/03/05(木)22:20 ID:h922Dn8C(2/2) AAS
>>162
DDDというかデザインパターンの話だけど
ファクトリ（系パターン）を使うのは
インスタンスの生成が複雑な時
たとえばAとBのインスタンスを常にペアで使いたいとか
いろんな条件でnewする部分が肥大化していくようなら
毎回書くよりファクトリパターン使う方がスマートでしょ？
166: 2020/03/08(日)23:30 ID:4J5clray(1) AAS
そうかなあ…一番DDDやりやすいのは関数型言語だと思う
ドメイン設計って、
•あるデータはどんなデータがANDないしORで組み合わさって出来てるのか
•業務プロセスはそれらのデータをどのように変換していくのか
の2点が主だと思ってるけど、
これらは代数的データ型とパターンマッチによってダイレクトに表現できて、
業務プロセスは関数の連続で簡潔に表現できる。
また純粋なビジネスロジックは作用のない関数によって表現され、
ビジネスロジック以外の部分が作用を持つ関数になるはずで、
作用のある無しを型レベルで区別する純粋関数型言語であれば、
省1
167: 2020/03/08(日)23:55 ID:2h+/wurX(1) AAS
作用？
168: 2020/03/09(月)21:19 ID:bHKN7jy6(1) AAS
左様でござる
169(1): 2020/03/09(月)22:12 ID:ajCpPJPb(1) AAS
Webみたいにステートレスで済むなら
関数型の方が簡潔に書ける部分もあるが
ビジネスロジックは複雑な状態遷移や
階層構造を持っていることが多いので
FPでもDDDはできるが
OOの方が向くことが多い
170(1): 2020/03/09(月)22:18 ID:aVP5r6mu(1) AAS
階層構造を持ってるからOOの方が向いてるってのはよくわからないな
171(2): 2020/03/09(月)23:12 ID:y1num/wG(1) AAS
？複雑な状態遷移があるとFPが向かないっていうのもよくわからないな
状態の数だけ型作って、遷移の数だけ関数つくればいいだけやん
OOPはむやみにクラス内に隠れた状態や依存を作って他のクラスとうまく合成されない物を作りがち
そんなことしてると、非同期な処理を並列化とかしようにも気にしないといけないことが増えて大変な労力だろうに
172(1): 2020/03/14(土)17:55 ID:JKHuUiBu(1) AAS
>>171
言いたいことはわかるが、websocketみたいなコネクション管理するものを
まるまる関数型で書くなら状態変化を含んだとしてもオブジェクト的に記述した方が
多分楽。
なんでもどっちかに倒そうとすること自体が悪パターンな気がするよ。
173: 2020/03/14(土)18:05 ID:ZFQFhT9Y(1) AAS
良いとこ取りしていけ
174: 2020/03/15(日)00:23 ID:UpO1XTWv(1/2) AAS
>>172
WebSocketかー。やったことないからやってみよう
175(2): 169 2020/03/15(日)05:56 ID:1/DFOu+E(1/2) AAS
>>170
継承や委譲で階層構造を表現できる
まあメジャー言語はたいてい
OOのパラダイム入ってるから
だいたいできるんだけど
>>171
＞状態の数だけ型作って
＞遷移の数だけ関数つくればいいだけ
実際にはゴチャゴチャになって
「大変な労力」だから
省4
176(1): 2020/03/15(日)08:25 ID:j83nFY2E(1) AAS
>>175
あんたに限らず関数型が大規模なプログラム書くのに向かないと思ってる層がちゃんと関数型プログラミングをしたことがなく先入観でもの言ってるのはよくわかった
177(1): 2020/03/15(日)08:38 ID:1/DFOu+E(2/2) AAS
>>176
あんたも決めつけで言ってるだけだろ
関数型で状態遷移を把握しづらいのは
強く実感しているし普及しない原因だ
178: 2020/03/15(日)09:21 ID:UpO1XTWv(2/2) AAS
>>177
それはどの言語でどんなことしようとして「強く実感」したの？
関数型言語が普及しないのは、単に先入観やOOP神話の影響で学ぼう使おうと思う人が少ないからだよ。
関数型プログラミングが普及しない理由は、当然だが関数型プログラミングの諸概念を表現するのに命令型言語が不向きだから。柔道着着て水泳するようなもんだ。
179(2): 2020/03/15(日)14:50 ID:7lggs81n(1) AAS
>>175
>継承や委譲で階層構造を表現できる
OOでは継承や委譲で階層構造を表現できると言われても
関数型の言語よりOO言語のほうがDDDには向いてるという論拠にはならないよ
少し古いスライドだけど、これ見て概要だけでも勉強して
外部ﾘﾝｸ:www.slideshare.net
180: 2020/03/15(日)18:32 ID:XbDoNvCk(1) AAS
一昔前のOOP厨と一緒だな。
歴史を学ばん奴は一生ループする。
181: 2020/03/15(日)23:47 ID:zobMuC0O(1) AAS
>>179 そうだよなと得心する事が多くて良い資料ですね
ドメインに継承や移譲が要るって考えてる人は是非とも読んで欲しいし、反例を挙げて欲しくなる
182(1): 2020/03/16(月)00:15 ID:PIKXUqlC(1) AAS
>>179
俺もこのスライドの作成者の本で関数型DDDに入門したクチだけど、本当にわかりやすかった
もともとHaskell, purescriptはやってて関数型には慣れてたけど、
DDDについては知らなかったので、せっかくだから関数型前提で書かれている本でと手にした。
Domain modeling made functional っていう本で、
DDDの解説はもちろん、関数型プログラミングの諸概念の解説もわかりやすく、
一冊で二度美味しい内容で、実用的な関数型プログラミングの入門書としても超おすすめ。
動画ﾘﾝｸ[YouTube]
ちなみにyoutubeにはこのスライドの発表動画もあったりする
183(1): 2020/09/16(水)23:15 ID:hC0if/qX(1) AAS
Matthias Felleisenの「How to Design Programs」を読んで関数型プログラミングに
興味を持ったものです。
次にモナドを勉強しようとしてHaskellの本を読んだがいまいちピンときません。
>>182さんが挙げられている本では、モナドを使ってモデルの実装をしているようですが、
モナドの使い方は理解できますか？
184(3): 2020/09/17(木)01:01 ID:m/PpcUvw(1) AAS
Scalaで良ければ、manning.comからでてる Functional and Reactive Domain Modeling にモナドでドメインサービス組み立てる話が掲載されてる。
なおFree Monadをベースとしているので軽く死ねる。
外部ﾘﾝｸ:www.manning.com
185: 183 2020/09/17(木)23:32 ID:pIiN+iyt(1) AAS
>>184
ありがとうございます・・・でもDomain modeling made functional をPDFでポチっちゃいました。
後で読もうと思います。
ところでDDDを学ぶ上で、大規模な開発経験が必要なんでしょうか？
自分は学生で、そのような経験がありません。
『How to Design Programs』では小さなプログラム作成の演習はありましたが、
それ以上の大きさのプログラム作成の方法はありませんでした。
DDDは大きなプログラムをつくるガイドになりますか？
186: 2020/09/22(火)23:49 ID:mxGu0eGU(1) AAS
>>184
これ
187(1): 2020/09/23(水)00:07 ID:NN2kaL4Y(1) AAS
>>184
これ読んでみようかと思ったら
＞読者は関数型言語とドメイン駆動設計に慣れている必要がある
とあるんだが、読むのにドメイン駆動設計の深ーい知識は必要だった？
188: 2020/09/23(水)06:16 ID:VKAwJeUe(1) AAS
DDD興味ある
大いに語るがよい
189(1): 2020/09/23(水)07:12 ID:SbRHy3fQ(1) AAS
>>187
必要最小限ではあるがScalaの文法解説と、各ドメインオブジェクトの解説は入っていたはず。
知っていれば理解が進みやすいくらいに考えてればいいはず。
190: 2020/09/23(水)19:36 ID:4eJQ0d8P(1) AAS
>>189
thx
191(1): 2020/09/30(水)19:59 ID:0r1wHLnO(1) AAS
DDDもそろそろバージョンアップせんと
OOPは時代遅れ
192: 2020/12/02(水)20:38 ID:E6FeESB6(1) AAS
Freeモナドなんて言語埋め込みDSLを作るってだけ
193: 2020/12/05(土)00:03 ID:FFFEgOY+(1) AAS
DDDいいよね！
なんちゃってOOPから脱出する際に役立ったよ
194: 2021/03/31(水)07:17 ID:PqSCUqXE(1) AAS
DDD、CQRS、イベントソーシング…
企業内システムでここまでやってるとこってあるんだろうか
参照系中心のシステムでDDDやるのは愚行？
195: 2021/05/18(火)06:36 ID:Z0RWJbQc(1) AAS
おれはさとった
名前がちがうだけのValueObjectクラスだけつくって
メソッド引数の位置を間違えられないようにしときゃいいんだ
それだけでいいんだ
バリデーションは入り口でやる
中は値が正しい前提でまったくチェック不要
それがDDD
196: 2021/05/19(水)20:38 ID:NeVz061v(1) AAS
それだけでDDDは語れないような…
いまだに集約がわからんよ
197(1): 2021/05/23(日)21:05 ID:hHIInayx(1) AAS
教科書が概念的でよくわからんことばっかほざいてる時点でおかしい
サンプルを一発提示すればああこんなのねって
それで終わるだろ！？
198: 2021/07/13(火)00:57 ID:FnRTq1rf(1) AAS
ガサッと取ってきて変更して全部更新！ってアホなんって思った
これの何がいいの？
199: 2021/07/13(火)22:24 ID:fj1E0qkc(1) AAS
CRUD で十分な単純なアプリならいらない
200: 2021/07/14(水)08:14 ID:wgyTk/up(1) AAS
>>197
2003年頃ならともかく。OSSのアプリが溢れている今の状況ならこのアプリのこの部分はこのパターンを使っているって示せると思う。
201(1): 2021/08/10(火)20:46 ID:R7L3+gXm(1) AAS
>>191
亀レスだが、OOPを補完するのがDDDだろうに
なんでDDDスレでOOPが時代遅れだと言えるのか疑問
202(1): 2021/08/10(火)23:57 ID:yd00h36W(1) AAS
>>201
OOPより上位レイヤーの概念なのでOOPを補完するものではないよ
Eric Evansの最初の本ではDDDの実装例としてOOPが使われただけ
関数型で実装する例もある
203(1): 2021/08/11(水)22:58 ID:AUz9CV9O(1) AAS
>>202
> OOPより上位レイヤーの概念なので
> Eric Evansの最初の本ではDDDの実装例としてOOPが使われた
そういうのを補完って言うのでは？
204: 2021/08/12(木)23:34 ID:1njm/kBk(1) AAS
>>203
お前は国語から勉強し直さないとこの先辛いぞ？
お前は概念とか言ってる場合じゃない
205(1): 2021/08/13(金)08:38 ID:yFah4eQP(1) AAS
ほかん
【補完】
《名・ス他》
足りない点を補って完全にすること。
OOPに足りない部分をDDDで補ってるって言いたかったのでは？
別に変だとは思えないけど
206: 2021/08/13(金)09:30 ID:4chv34Gy(1) AAS
OOPを補完するのがプログラミングだろうに
なんでプログラミングスレでOOPが時代遅れだと言えるのか疑問
OOPに足りない部分をプログラミングで補ってるって言いたかったのでは？
207: 2021/08/13(金)11:25 ID:klCtaRRF(1/2) AAS
OOPはプログラミングを補うものでありプログラミングがOOPを補う訳ではない
208: 2021/08/13(金)11:56 ID:VPbn/mvQ(1) AAS
>>205
補完などではない
そもそもOOPなどと書くから話がおかしくなる
DDDはOODを包含した概念である
209: 2021/08/13(金)13:49 ID:iLxHQIIJ(1) AAS
OODと言い換えたところで補完もしてなければ包含もしてない
DDDをOOの文脈でしか理解できない人は抽象概念の理解がもともと不得意なのか
日本人の書いたなんちゃってDDD本で分かったつもりになってるか
そもそもOO以外を知らないか
210: 2021/08/13(金)14:28 ID:klCtaRRF(2/2) AAS
お前はDDDを学んでもOOP及びOODには何の影響もないみたいだけど、俺は別にDDDで学んだ知識がOOP／OODに役立ってるので、別にどうでもいいっす。
なんで役立ったのか想像できないのなら、その程度ってことでしょう。
211: 2021/08/13(金)15:21 ID:cdK9y9f/(1) AAS
ブホッw
212: 2021/08/14(土)07:58 ID:3YTtOTVG(1) AAS
OOPにありがちな、車やエンジンを例にした説明より
DDDの方がしっくりくるというか
あ、OOPでこんなことができるのかと目から鱗だったな
213: 2021/08/14(土)15:27 ID:db9EEEoY(1) AAS
いつの時代になってもITの方法論は「方法論オナニストに都合のよい飯の種」の域を出ない
214: 2021/08/14(土)15:31 ID:4CNv29yk(1) AAS
建設業のように国が規格を決めてしまえばよかったんだ
国所属の認定団体に承認された関数以外使ってはいけません
215: 2021/09/16(木)15:51 ID:PMPdG/+a(1/2) AAS
DDDとは、「ドメイン知識(モデル)」を「駆動」して「開発」する開発手法であって、何か特定のアーキテクチャをあらわすものではない
216: 2021/09/16(木)15:54 ID:PMPdG/+a(2/2) AAS
嘘言いました
最後のDはDevelopmentじゃなくてDesignだったわ
恥ずかしー
217: 2021/09/16(木)19:58 ID:d3wmnSJn(1) AAS
もーやだー
218: 2021/09/26(日)11:30 ID:0AJzxi3v(1) AAS
設計はアーキテクチャを示すものじゃない
言葉が違えば意味が違う
219: 2022/05/07(土)06:20 ID:Japg54lQ(1) AAS
DDDは大量データ更新に弱い
10万件のレコードに同じ値をセットする処理に途方もなく時間がかかる
220: 2022/07/27(水)17:37 ID:hi2YYXJ0(1/2) AAS
カルト宗教だよね
設計というのはパフォーマンス要件の整理と実現に当たってのアーキテクチャを考えるために必要なわけで
機能要件にSLAがないだなんてことは設計するならばありえないし、
じゃあその要件に到達するためにシステムやミドルウェアをどう使っていくかがアーキテクトの肝なところじゃん
APPサーバに閉じた議論しかしてない時点で雑魚システムしか作れんし
雑魚システムにそもそも設計なんざいらんだろって話よ
こういう連中が言い出しそうなこと、DBは抽象化できる
そもそもファイルを保存するならテキストでもいい
依存性の逆転を駆使すればインタフェースに依存させることができるので、アプリから実装詳細が消える！
それでDBがやってくれてるトランザクション制御や成約、整合性の解決を
省2
221: 2022/07/27(水)17:39 ID:hi2YYXJ0(2/2) AAS
型システムの理解も貧弱、DBMSの理解も貧弱、なんならネットワーク・プロトコルの理解も貧弱
一生システム完成させる気ないやる気なしエンジニアの最後の拠り所だろ
222: 2022/07/27(水)20:57 ID:i1UDtnj5(1) AAS
だいぶ詳しい反論だなw
223: 2022/07/27(水)21:51 ID:gDp6GlMI(1) AAS
外部ﾘﾝｸ:enterprisecraftsmanship.com
DDDでバルク処理
そこまで拘らなくていいんじゃないかなと言う感想
224: 2023/09/22(金)05:22 ID:dV2V1da1(1) AAS
これってどうやって気にするの？
225: 2023/09/28(木)03:45 ID:i8VmgZE9(1) AAS
ｺﾞｼｺﾞｼ(-_＼)(/_-)三( ﾟДﾟ) ｽ､ｽｹﾞｰ!
226: 2023/12/03(日)23:52 ID:p5/cY/Es(1) AAS
テスト
227: 2024/12/06(金)22:29 ID:IVgCNi6x(1) AAS
関数型DDDの本の作者のアーキテクチャが話題になっている
Repositoryはいらない
大事なのはIOをロジックの中から排除せよということらしい
以下のように"端に寄せる"
IO
ビジネスロジック
IO
目から鱗だった
IOへの依存をなくすことでテストしやすくなるしモックもいらない
228: 2024/12/07(土)18:42 ID:cdxtdz0L(1) AAS
ビジネスロジックはパイプラインで構築して副作用がないようにする
229: 2024/12/08(日)00:14 ID:fPMU02oZ(1) AAS
DDDは素晴らしいと思うけど、プロジェクト内の他エンジニアのスキルが低いとアンチパターンになるんだよな
230: 2024/12/08(日)14:38 ID:5KF429T4(1) AAS
DDDって再現性ないじゃんw
偽科学
231: 2024/12/08(日)15:54 ID:yVSjHkLG(1/2) AAS
設計に再現性はないよ
要件が全く同じということがないから
だから難しい
232: 2024/12/08(日)15:56 ID:yVSjHkLG(2/2) AAS
IOを"端に寄せて"ビジネスロジックはパイプラインで実行して不変データ構造にするというアイデアマジで凄い
これからこの設計にする
233(1): 2024/12/08(日)19:27 ID:xllqP0wk(1) AAS
そのぶんリソースバカ食いのクソアプリの出来上がり
234: 2024/12/09(月)00:32 ID:+1IlmX9/(1) AAS
根っこに流れる考えは、コマンドラインシェルでコマンドをパイプで繋いでいくことと同じだけどね。
一連のワークフローを一つのコマンドとみなして、さらに大きなワークフローに組み込むところとかもね。
235: 2024/12/19(木)14:37 ID:fGxiJNMh(1) AAS
F#で遊んだ時シェルのパイプじゃんとは思ってた
関数型言語の原点てシェルスクリプトなんか？
236(1): 2024/12/20(金)12:36 ID:xSkBLBiw(1) AAS
>>233
そこで遅延評価ですよ
237(1): 2024/12/20(金)13:57 ID:UU1VM3lj(1) AAS
>>236
やってから言え
遅延評価こそリソースバカ食いだ
238(1): 2024/12/20(金)18:04 ID:eZ4ILWvg(1/2) AAS
>>237
今の時代リソースなど死ぬほどあるのだよ
自作でサーバー組み立てる場合でもメモリ64Gなんて普通だし
239(1): 2024/12/20(金)18:26 ID:zuM8e09I(1/3) AAS
>>238
それはお前の作ってるものがしょぼいからだよ
240: 2024/12/20(金)18:34 ID:zuM8e09I(2/3) AAS
クラウドはリソース使えば使うだけ課金
241(2): 2024/12/20(金)19:25 ID:Sq/wbvsq(1/3) AAS
遅延評価がリソース食うっていつの時代よ？
むしろ今は遅延評価しないとリソースをバカ喰いする時代だぞ
キャッシュと勘違いしてない？
ディープラーニングとか全部遅延評価だ
それこそ>>239の作ってるものがしょぼいという証明になったな
242: 2024/12/20(金)19:31 ID:eZ4ILWvg(2/2) AAS
>>241
多分Haskellの遅延評価のことを言ってるのでは？
メモリをドカ食いすると聞いたことがある
しかしそれは言語のインプリメンテーションやデータ構造の問題であり
一般的な遅延評価がメモリをくうわけではないのよな
243: 2024/12/20(金)20:48 ID:zuM8e09I(3/3) AAS
>>241
だからやってから言えって
Haskellの不評のひとつが遅延評価だ
244: 2024/12/20(金)21:17 ID:Sq/wbvsq(2/3) AAS
Haskell使いは大変でちゅね〜
245: 2024/12/20(金)22:16 ID:L0BexGzI(1) AAS
遅延評価だからリソースバカ喰いするわけじゃないのにね
バカは因果関係がわからないからな
246: 2024/12/20(金)22:30 ID:Sq/wbvsq(3/3) AAS
Haskellしか書いてないんじゃないの？
知らんけど
247: 2024/12/21(土)17:16 ID:unOGov3F(1) AAS
ひぐちデブすぎんか？
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.793s*