• はてなブックマーク
  • テクノロジー
  • DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろしているイメージの強いくまぎさんに質問させていただきました。 最近はソフトウェアの設計について調べると、DDDについての記事ばかりで辟易する一方、私がエンジニアになった頃にDDDに勢いがあった影響もあって私自身DDD以外の良い設計とされているものを知らず、DDDに胡散臭さを感じつつもDDDの考え方にとらわれている、毒親の影響を受けた子供のような状態から抜け出せずにいます。 その最たる例がリポジトリパター
  • Twitterでシェア
  • Facebookでシェア

DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろしているイメージの強いくまぎさんに質問させていただきました。 最近はソフトウェアの設計について調べると、DDDについての記事ばかりで辟易する一方、私がエンジニアになった頃にDDDに勢いがあった影響もあって私自身DDD以外の良い設計とされているものを知らず、DDDに胡散臭さを感じつつもDDDの考え方にとらわれている、毒親の影響を受けた子供のような状態から抜け出せずにいます。 その最たる例がリポジトリパター

テクノロジー カテゴリーの変更を依頼 記事元:mond.how
適切な情報に変更
445users がブックマーク コメント 57

    記事へのコメント57件

    • 注目コメント
    • 新着コメント
    baronhorse
    “あらゆる教条主義は基本的に嫌いだけど最終的に似るのは別に良い” 教科書的に読むんじゃなくて、さんざ試行錯誤したあとで、そうそうこうなるよねって読むものなんだよな

    その他
    komutan1
    インターフェースがRepository::findById(id)で実装が1行しかないコードを毎回書かせられるのほんとつらい。

    その他
    kikuchi1201
    “言い換えれば、将来のプログラミングの難度を下げる事ができるのが良い抽象化、そうでないならどんなプラクティスも自己満足です。” ここ刺さりました

    その他
    justgg
    同意。いい事書いてある。一方で昔遭遇した本当に酷いコードの数々を思い出すと、酷いコードよりはたとえ教条的であっても整理されていた方がマシだとも思う。

    その他
    strawberryhunter
    教条主義は良くない。いつの間にか合理性が忘れられて宗教になる。真に良いコードを書くことよりも信仰を守ることに熱心になったら終わり。

    その他
    fumobox
    この手の話って、結局のところ、お部屋の片付けテクニックを難しく言い換えているだけなんじゃないかなと思う。

    その他
    tacamula
    Read系とWrite系を分離すると楽。Read系にまでDDDを持ち込むとツラくなる。

    その他
    tockri
    DBにどうアクセスするかって話はDDD全体の中ではだいぶ枝葉末節なので、そんなことより序章とか1章とか読んで「やっぱ名前大事だよね！」ってなろう

    その他
    marshi
    dddで一番主張されているのはビジネス上の要求とコードを対応させろという話だと思うのでリポジトリとかはそのためのテクニックのひとつにすぎない。

    その他
    kagerouttepaso
    古来鉛筆と紙とファイリングで管理されていた業務をシステム化するんだからレポジトリパターンに回帰するのは必然だと思う。再利用しやすいファイリングのルールを考える仕事という意味で本質は変わっていない。

    その他
    shun_libra
    “膨れ上がり続けるソースコードと向き合って増加し続ける複雑さをどう整頓するかがすべて”ほんそれ。

    その他
    kat21
    バランスいい。僕もこんな感じかな

    その他
    NetPenguin
    激しく同意する。 "アプリロジックという究極的には再利用性皆無の極北からグラデーションのように段階を経てOSやDBのAPIという普遍性の塊までの間をどのように整理区分するかがプログラマに課せられた仕事であって、"

    その他
    dorapon2000
    “拡張性やエンバグのしにくさ(セキュアコーディングとか言いますよね)よりもコードの書き直しやすさと消しやすさに重点を置いています。”

    その他
    justgg
    justgg 同意。いい事書いてある。一方で昔遭遇した本当に酷いコードの数々を思い出すと、酷いコードよりはたとえ教条的であっても整理されていた方がマシだとも思う。

    2024/11/19 リンク

    その他
    estragon
    “仮にこの部分だけを別の目的で使いまわすならどんなインタフェースが露出していれば使いやすいか、を考える事が自ずと責務の分割と凝集性を高めてくれます”、”ある程度サービスの概形が固まってきてから内部を冷

    その他
    uyyy
    データベース切り替えとかそうそうあると言われるとなぁ

    その他
    skypenguins
    「あらゆる教条主義は基本的に嫌いだけど最終的に似るのは別に良い 凝集とか難しい言葉を使うより再利用性を意識する方が直交性に効く 依存が少なくて消しやすいコードは正義、コードが若い時ほど消しやすさを優先」

    その他
    awkad
    それこそ業務システム構築エアプでは？と思う。GAFAM様も銀行システムとか作れてないよね？きっとエンジニアは優秀だからDBベッタリでも酷いことしない、という暗黙のGAFAM様理論がある。そんなのSIでは通用しない

    その他
    namisk
    “再利用性を優先することが直交性を高める為の近道である” “再利用性を優先した結果、リポジトリパターンと呼べる形にコードが落ち着く事自体はそんなにおかしな話ではありません”

    その他
    onesplat
    良い話

    その他
    queeuq
    dbをすげ替えられないよりすげ変えれるほうがいいよね！みたいなべき論で工数とか全部忘れて採用しちゃう印象。

    その他
    parrying
    findByIdが全てのリポジトリに生えてるみたいなのは何も抽象化していない例なのでそんな無駄レイヤーなら取り除いたほうがマシである。あるあるだけど、DDDの問題ではない

    その他
    tg30yen
    >「仮にこの部分だけを別の目的で使いまわすならどんなインタフェースが露出していれば使いやすいか、を考える事が自ずと責務の分割と凝集性を高めてくれます

    その他
    kagehiens
    マジそれですよね。→“崇める人もいますが、一介のコード書きから見たらそれらすべて「コード整理術」の一部でしかありません。”

    その他
    mask8686
    ほんと宗教っぽい。布教してる人(自称コンサル)とか特に。

    その他
    tockri
    tockri DBにどうアクセスするかって話はDDD全体の中ではだいぶ枝葉末節なので、そんなことより序章とか1章とか読んで「やっぱ名前大事だよね！」ってなろう

    2024/11/18 リンク

    その他
    hogeaegxa
    ActiveRecordがクソみたいな話に聞こえるけど、DDDってこういうことだっけ？

    その他
    togusa5
    ————拝承

    その他
    nemoba
    日本でDDD批判が多いのは、古くから根付くデータモデルアプローチと、オブジェクト指向のユースケースアプローチが、永続化レイヤでぶつかってるだけだよ。前者はアジャイルアプローチがそもそも懐疑的なだけ

    その他
    hatebu001
    インターフェースが役にたったためしがない。エディタでジャンプがめんどくなるだけ。

    その他
    wakwak3
    “熊崎 宏樹”

    その他
    tacamula
    tacamula Read系とWrite系を分離すると楽。Read系にまでDDDを持ち込むとツラくなる。

    2024/11/18 リンク

    その他
    trace22
    人間とシステムとどっちの寿命が早いかで結論違うかな。永遠にメンテし続けるシステムなんてあんのかね？銀行系が結局COBOLから抜け出せないとか言ってるからないとは言い切れんのだが。

    その他
    phain
    信仰を強化すると奇跡が使える

    その他
    unmarshal
    “再利用する予定のないロジックでも再利用性を重視したコードを書け” → 「Don't DRY Your Code Prematurely」https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html?m=1

    その他
    versatile
    素晴らしい設計でつくった100のPJがあって、生き残るのは20くらい。そのうち機能追加するのは4くらい。設計通りうまく追加できるのは2くらい。実装者が恩恵を感じられるのは1くらいって思ってる。

    その他
    hecaton55
    良いコードを作るにはセンスと経験が必要というように読んだ。センスを磨くのは大変だけど経験は積めるからそちらに力を入れるのが成長するには近道かな

    その他
    yamadar
    "将来のプログラミングの難度を下げる事ができるのが良い抽象化、そうでないならどんなプラクティスも自己満足" "「再利用する予定のないロジックでも再利用性を重視したコードを書け」"

    その他
    c-matt
    直交性って難しい概念だと思うのだけど！ベクトルのアレをベースとして、システムの文脈になるともうちょっと意味合いが付加されている感

    その他

    注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

    アプリのスクリーンショット
    いまの話題をアプリでチェック！
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

    DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろしているイメージの強いくまぎさんに質問させていただきました。 最近はソフトウェアの設計について調べると、DDDについての記事ばかりで辟易する一方、私がエンジニアになった頃にDDDに勢いがあった影響もあって私自身DDD以外の良い設計とされているものを知らず、DDDに胡散臭さを感じつつもDDDの考え方にとらわれている、毒親の影響を受けた子供のような状態から抜け出せずにいます。 その最たる例がリポジトリパター

    DDD以外の設計手法についてご教示いただきたく、DDDの主張をある程度正確に理解した上でDDDをこき下ろし...

    ブックマークしたユーザー

    • shun_libra2025/07/17 shun_libra
    • techtech05212024/12/30 techtech0521
    • okbm2024/12/26 okbm
    • chidakiyo2024/12/22 chidakiyo
    • ryskosn2024/12/02 ryskosn
    • spicamao2024/11/23 spicamao
    • kat212024/11/21 kat21
    • muuran162024/11/21 muuran16
    • yug12242024/11/21 yug1224
    • radiocat2024/11/20 radiocat
    • motchang2024/11/20 motchang
    • onichannn2024/11/20 onichannn
    • kazre2024/11/19 kazre
    • hem62024/11/19 hem6
    • matuimaui4112024/11/19 matuimaui411
    • tosi292024/11/19 tosi29
    • tmonz632024/11/19 tmonz63
    • kihala2024/11/19 kihala
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    同時期にブックマークされた記事

    いま人気の記事 - 企業メディア

    企業メディアをもっと読む

    はてなブックマーク

    公式Twitter

    はてなのサービス

    • App Storeからダウンロード
    • Google Playで手に入れよう
    Copyright © 2005-2026 Hatena. All Rights Reserved.