プログラムとはメタファーであり、現実を、もしくはそれに準ずる写像的な世界観を、コードに忠実に再現するものでは必ずしも無いと考える。この記事の増田は「過度な抽象化」とも書いているが、プログラムというか、そもそも言語そのものが物事の全てを表象できるものではなく、ある一側面の一イメージしか切り取れない不完全なものだし、それ自体が問題ではない。現実とソフトウェアの溝を、ユーザーとエンジニアの溝を、ドメインとソースコードの溝を、いかにして埋めるかというのが、ドメイン駆動設計の本質だし、その埋め方についてはエリックエバンスは一例を示しているに過ぎない。EntityやValueObjectなど、必要なら使えば良いし、不要なら使わなければ良いのだ。ただし、元々何が問題なのか、問題だったのかという点について、いかにして向き合うかが肝要であり、それは技術論や方法論の話ではない。

ドメイン駆動設計の記事を書いたり、勉強会で発表をしている人間は、原典やそれに付随するドキュメントの内容を、無批判に信奉し、そのようにしなければならないという強迫観念に追われているのではないか。そもそも、本当に理解しているか怪しいし、不安だから教科書の内容にしがみつこうとするのだろう。さらにこの手の連中は、昨今のCQRSやイベントソーシングやマイクロサービスなどとも絡めて話をし出すから、タチが悪い。「ドメイン駆動設計はこの手の技術スタックと相性が良い」という言葉を何度も見かけたが、技術的な方法論はそもそも無関係だったはずだし、そうやって安易に結びつけてしまうから、ユーザーが置き去りになって来たんじゃねーのと、暴言でも吐きたくなる。問題の本質はどこにあったのかを、聖典の内容や、流行り廃りの技術とは切り離して、エンジニアは三思九思すべきだ。

別にこうあらなければならないという法律や決まりは無いし、好きにやれば良い。モデルと1対1にならなければ、分割する事を選択するのも一つの向き合い方だ。ドメイン駆動設計の信者ににゃんにゃん写真でも撮られて、ばら撒くと脅迫されているのであれば勿論話は別だ。恥ずかしい写真を魚拓されたくなければ、とりあえずEntity、ValueObject、Repository、Service（笑）位は最低限、用意するのが身のためだろう。

自分の頭で考えて、自分の責任で判断するという当たり前の事に立ち返りたいものだ。ドメイン駆動設計という盲目的な宗教からいかにして抜け出すかが今後のエンジニアの課題だろう。

追伸

増田はドメイン駆動設計が大好きです😘

Permalink | 記事への反応(0) | 08:17

■anond:20210425022947

以下はあくまで個人の解釈だから異論は認める

ドメイン駆動設計ってあくまで設計手法っていうかビジネスロジックのモデリングまでが本分だから

システムドメイン（領域）にビジネスドメインで履いていた土足のまま踏み入ってはいけない

ビジネスの理屈を一対一でシステムに持ち込むのはナンセンス

※補足追記：基本設計したら詳細設計するけども、そこでビジネスロジックをシステムロジックに翻訳するからコードレベルでは一対一にはならないということ

概念の次元が違うのだから現実に漫画の理屈を持ち込むなっていうレベルの話（ビジネスが漫画レベルという意味ではない）

モデリングによって現行のビジネスの問題を洗い出し、それを課題として解決（仕事を楽に）するのがシステム

それも一回で終わりじゃなくてシステム化したビジネスを再びドメインモデル化して分析、課題をシステムで解決ってサイクルを回していかなくちゃいけない

システム側も細かいこと言えば領域が分かれてるからそれぞれの領域に合わせて駆動方法は変えなきゃうまく回らない。

データレイク周りならデータ駆動型の方が適しているし、逆にアプリケーション側でビジネスやUXを無視してデータ主体で走るのは阿呆の所業だし、

馬鹿の一つ覚えで〇〇駆動設計だの開発だの一本槍でパワープレイするやつが多すぎなんだよ！　適材適所って理解しろよ！

ちゃんと各分野のスペシャリストを雇って意思決定層に組み込んだ方が結果的に時間や金なんかのコストが少なくなるよって話が通じないよね

Permalink | 記事への反応(0) | 02:17

■anond:20210425022947

っていうかドメイン駆動設計ってクライアントアプリとかやってる人なら意識せずに普通にやってることじゃないの？

web アプリだからフレームワークに沿わずに特別なことにみえるだけでさ

Permalink | 記事への反応(0) | 00:01

2021-04-25

■anond:20210425022947

Wikipedia読んでもドメイン駆動設計がどういうことなんかさっぱりわからんやで

この前ホッテントリに入ってたオブジェクト指向の増田みたいにわかりやすく解説してくれやで

Permalink | 記事への反応(0) | 22:30

■DDD(ドメイン駆動設計)、理念に大賛成、実装に大反対。

※追記あり。最後の追記は 2021/04/25 21:40頃※

タイトルの通りのことを思っているけど、顕名のブログで書くと社内で干されるので、増田に書く。社内の心理的安全性がそんなに低い訳ではないけども、潮流が凄いので今は慎重に振る舞いたい。

この記事を見て「キミはDDDのことを誤解している」と思われた方はコメント等で優しく（易しく、ではない）ご指摘願いたい。

※この記事では Web Application を前提とした話になっている。

DDDとは？

https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88

DDD、ここがイケてる

ソフトウェア開発者は開発対象のドメインのことをほとんど知らない、という問題意識およびその提起。
俗に言う「ビジネスサイド」の人間との共通言語を整備するべきだ、という提言。
ドメインモデルの構成要素のうち「エンティティ」「値オブジェクト」あたりの概念は、俗に言うビジネスサイドの人間も持たなくちゃいけない。DDDはその学びの道標として非常に優れている。

DDD、ここがイケてない

共通言語たるドメインモデルを、そのままコードと1対1対応しなければならない、という思い込みや風潮。
- 既存のWAF(Web Application Framework) の利点を潰してどうする…
ドメインモデルの構成要素のうち「リポジトリ」等はソフトウェアの中に閉じた世界の話であって、俗に言うビジネスサイドの人間との共通言語には登場しなくて良いことが圧倒的に多い。設計を遅延させる原因になっている。
- 名前から考えれば、DDDの効用の範囲は「共通言語の整備」と「共通言語の会話から設計に落とし込む際のベストプラクティス」あたりであって欲しいのに、余計なお世話。
過度な抽象化

じゃあ、どうすんの？

エンティティやその周辺のドメインモデルの話は、いわゆるビジネスサイドの人間との共通言語として、噛み砕いて共有したい（既に進行中）
ソフトウェアの設計としては、3月にバズってた記事 Only My Rails Way のような方針でありたい。欲を言えば静的型付け言語に乗り換えたいが、それは叶わぬ望み……。。。

短く言うならば「DDDの理念は取り入れるが実装は取り入れない」

(参考) 筆者のポジションと近況

データベーススペシャリストの立場で、また俗に言う「テックリード」の立場で、情報システムやWebサービスの設計と実装に従事。
技術的な上司はチーム外。チーム内では筆者が一番上。
社内のよそのチームが「DDDいいぞ」と言って布教しようとしてきてて、つらいお年頃。

追記＠2021/04/25 21:40頃

夜中に投稿したのに多くの方に読んでもらえて嬉しく思います。コメントなどなどありがとうございます。以下、補足です。

筆者にとっても普段はWAFという語は Web Application Firewall を指します。わざわざWAFの正式スペルを文中に書いたのは、通常と異なる言葉遣いであるから、です。
「既存のWAFの利点を潰してどうする」が言うところの利点の主たる部分は、junior developer 職の人を新たにチームに招き入れる際に、当該言語やWAF(frameworkの方)、そして基本情報レベルのセキュリティや通信の知識さえあれば容易に参画可能であるという利点です。seniorならまだしも、juniorを迎え入れるときにDDDの知識を持ってる人を必須にしたり on boarding の時点でDDDの話をしなくちゃいけないのは、コストに見合わないと判断しています。

あと、素晴らしい引用に感謝したいのですけれども、

「一般的に言えることだが、使っているフレームワークとは争わないこと。フレームワークと対立してしまった時には、ドメイン駆動設計の基本を保ちながら、詳細は捨て去る方法を模索すること。」エヴァンス本 p157
https://b.hatena.ne.jp/entry/4701728015809111618/comment/sonota88

例えば、アプリケーションのディレクトリ構造をDDDの用語に合わせたものにするという行為は、ここで言うところの「対立」に相当すると考えています。「基本」すなわち理念だけ存分に私たちのアプリケーションに取り込みたいものです。

少し違う角度の話をすると、初っ端からDDD前提のWAF(frameworkの方)を、できれば静的型付け言語で（←個人的な趣味）、新しく開発してそれを普及させることによって、当該WAFを学んだ人は自然とDDDも身に付いているという文化を作ることには熱い賛同の言葉を贈りたいと思っています。

Permalink | 記事への反応(10) | 02:29