X
【DDD】ドメイン駆動設計【エリック・エヴァンス】
0127デフォルトの名無しさん
垢版 |
2018/10/24(水) 09:23:12.56ID:HQt07idp
>>125
講師がひとりで勝手に盛り上がってて寒いセミナーだったな
マーケ視点で物事を考えない典型的駄目エンジニアって感じだから内容も薄い薄い
0128デフォルトの名無しさん
垢版 |
2018/10/25(木) 01:29:02.78ID:c44lxtY/
こんなやつらがDDDやってるんだなってのがわかって結構面白かったけどね
今日の内容で本書きます！って言われたときはさすがに周り失笑してたけど
0131デフォルトの名無しさん
垢版 |
2019/04/25(木) 20:00:13.26ID:NTtreDXN
ドメインが複雑じゃないとあんまり意味なさそうなのは感じ無くもないけど、将来の改修のしやすさのための布石と思えばいいのかな。
0132デフォルトの名無しさん
垢版 |
2019/05/06(月) 12:07:22.28ID:y1ayn2s5
>>131
　ドメインモデルが有効に機能するのって、イラレ、フォトショ、動画編集、オフィス系のようなパッケージアプリぐらいだと思う。

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

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

これ結構いい本
Packtのサイトでセール中なのか今なら10$で買える
0139デフォルトの名無しさん
垢版 |
2020/02/08(土) 08:56:40.52ID:YyWxF9Co
モデル層とデータストア層って分離できないのかな。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

モデル(∞)-テーブル(1)のような関係になりそうです。
それを結合させられる中間層（リポジトリ？）を自分で考えたいと思います。
0148デフォルトの名無しさん
垢版 |
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:
　　　　# ...
0149デフォルトの名無しさん
垢版 |
2020/02/11(火) 13:38:06.66ID:v/oRLdRM
>>147
>テーブル上にまたがった（リレーションされた）データを、
>どうモデルに切り分けると良いか考えたいと思います。

それはモデル中心じゃなく既存テーブル中心設計じゃないか？
0151デフォルトの名無しさん
垢版 |
2020/02/11(火) 21:46:53.70ID:v/oRLdRM
>>150
DDDのようなモデル中心の設計では
ビジネス要求だったりユースケースだったり
アプリケーションの外部仕様を満たすために最適なドメインモデル考えるのが先

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

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

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

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

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

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

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

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

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

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

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

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

Sum Typeを作りやすいかどうかや
value object用のimmutableオブジェクトを作りやすいかどうかみたいな部分
RustやSwiftのenumだったりKotlinのdata classみたいなやつ
0157デフォルトの名無しさん
垢版 |
2020/02/16(日) 13:43:23.03ID:Xiaae5hS
ドメインモデル的にDBは検索可能なファイルフォーマットみたいな考え。
PDFやPSDファイルを考えるとわかりやすい。ファイルから読み出すとドメインモデルになる。
0162デフォルトの名無しさん
垢版 |
2020/02/20(木) 22:05:54.44ID:ABNkvVkH
未だにファクトリーだけメリットがわかりません
newとなにが違うんですか？
0164デフォルトの名無しさん
垢版 |
2020/03/05(木) 22:14:17.50ID:h922Dn8C
>>152
オブジェクト指向言語の方が
DDDに基本的に向いていると思う

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

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

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

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

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

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

FPでもDDDはできるが
OOの方が向くことが多い
0171デフォルトの名無しさん
垢版 |
2020/03/09(月) 23:12:50.10ID:y1num/wG
？複雑な状態遷移があるとFPが向かないっていうのもよくわからないな
状態の数だけ型作って、遷移の数だけ関数つくればいいだけやん

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

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


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

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

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

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

https://youtu.be/dEKvIxsERAI
ちなみにyoutubeにはこのスライドの発表動画もあったりする
0183デフォルトの名無しさん
垢版 |
2020/09/16(水) 23:15:57.30ID:hC0if/qX
Matthias Felleisenの「How to Design Programs」を読んで関数型プログラミングに
興味を持ったものです。
次にモナドを勉強しようとしてHaskellの本を読んだがいまいちピンときません。
>>182さんが挙げられている本では、モナドを使ってモデルの実装をしているようですが、
モナドの使い方は理解できますか？
0185183
垢版 |
2020/09/17(木) 23:32:13.91ID:pIiN+iyt
>>184
ありがとうございます・・・でもDomain modeling made functional をPDFでポチっちゃいました。
後で読もうと思います。
ところでDDDを学ぶ上で、大規模な開発経験が必要なんでしょうか？
自分は学生で、そのような経験がありません。
『How to Design Programs』では小さなプログラム作成の演習はありましたが、
それ以上の大きさのプログラム作成の方法はありませんでした。
DDDは大きなプログラムをつくるガイドになりますか？
0187デフォルトの名無しさん
垢版 |
2020/09/23(水) 00:07:54.77ID:NN2kaL4Y
>>184
これ読んでみようかと思ったら

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

とあるんだが、読むのにドメイン駆動設計の深ーい知識は必要だった？
0188デフォルトの名無しさん
垢版 |
2020/09/23(水) 06:16:40.99ID:VKAwJeUe
DDD興味ある
大いに語るがよい
0189デフォルトの名無しさん
垢版 |
2020/09/23(水) 07:12:30.61ID:SbRHy3fQ
>>187
必要最小限ではあるがScalaの文法解説と、各ドメインオブジェクトの解説は入っていたはず。
知っていれば理解が進みやすいくらいに考えてればいいはず。
0192デフォルトの名無しさん
垢版 |
2020/12/02(水) 20:38:28.14ID:E6FeESB6
Freeモナドなんて言語埋め込みDSLを作るってだけ
0194デフォルトの名無しさん
垢版 |
2021/03/31(水) 07:17:34.67ID:PqSCUqXE
DDD、CQRS、イベントソーシング…
企業内システムでここまでやってるとこってあるんだろうか
参照系中心のシステムでDDDやるのは愚行？
0195デフォルトの名無しさん
垢版 |
2021/05/18(火) 06:36:21.05ID:Z0RWJbQc
おれはさとった

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

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

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

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

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

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

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

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

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

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

一生システム完成させる気ないやる気なしエンジニアの最後の拠り所だろ
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況