  |
はてなキーワード: DDDとは
GoMockってのはGo言語のライブラリで、依存するinterfaceをテスト用モックに置き換えてくれる。
それで、テスト中のモックの期待される振る舞い等を簡単に定義できるのだ。
期待される振る舞いってのは、モックのメソッド呼び出しやその引数とかだな。
期待される呼び出しが無かったり、引数が違ったりするとテストが失敗してくれる。
非同期処理のテストだとよく、wg.Done()をモックにさせたりする。
けれどそのうち辛くなってくる。
つまり、たくさんのinterfaceに依存するサービスオブジェクトのメソッドをテストしようとすると、たくさんのモックのたくさんのメソッド呼び出しの全部の期待される振る舞いを書かないといけない。
モックのメソッドの戻り値によってサービスオブジェクトのメソッド内の挙動が変わる。
すると連鎖的に、メソッド内で続いて呼ばれるモックに期待される挙動も、変わる。
依存interfaceが増えるとこの場合分けが指数関数的に増える。
当然だ。
Go言語にはテーブルドリブンテストっていう、テストケースは配列に簡単にまとめられると良い、という慣習・哲学がある。
しかし俺のサービスオブジェクトはテストケースが肥大化複雑化しすぎてしまったようだ。
モックの期待される挙動を細かくケースに分類して配列にするのは恐ろしく辛い作業だ。
やりたくない。
どうしてこうなったかは明らかだ。
モノシリックで巨大で複雑なものは凡人には扱えないからやめとけ、と偉い人は言う。
やったよ（見様見真似で）。
でもじつはここはまだ山麓だったのです。
分け入っても分け入っても青い山。
おれはどこに行けばいいのだ。
参考文献
https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
ソフトウェア開発における名著とされる読みものがある。かつて、そういった著作のエッセンスをひたすら抜き出して黙々とまとめていくはてなダイアリーが存在した。2010 年代のことである。GoF のデザパタ本とか UNIX 哲学とかピープルウェアとかそういうの。ジュンク堂の本棚でいえば「SE 読みもの」というやつだ。業界に入って間もなかった当時の自分は、技術的な相談ができる大人が周囲にいなかった。いま思えば、残業中のオフィスで長いコンパイルを待つあいだ、ぼんやりとこのはてダを読み、目の前のやるせないソースや、所属するチームが置かれた状況について思いを巡らせながら、ガス抜き感覚でこのはてダを読む時間が好きだった。どの項目も歯切れの良い紋切り型の文体で読みやすく、読んでいるうちに不安のかたまりがスルスルと解かれていき、気持ちがラクになるような気がしたのだった。
その後、わたしがアラサーになるころには、そこで紹介されていた大部分の原著は書店で購入し物理的に所持するに至っている。あのはてダがなければ、本屋でも仕事関連の棚で足を止める人間にはなっていなかったのではないかと思う。その後、当時のはてダの内容を抜粋したものが秀和システムで書籍化され出版される運びになった。ファンだったわたしは発売をとても楽しみにしていた。が、本屋に並んだ書籍を手にとってみると、あのはてダにあった宝物のような輝きはすっかり失われていた。なぜかはわからないけれど、説得力が損なわれている気がしたのだった。書籍化の都合、はてダに貼られていた Amazon へのリンクが取り払われ、原著との接続性がいくぶん薄らいでしまったせいかもしれない。またこの書籍化に伴って、はてダも閉鎖されてしまった。もっとも新刊の売上にも関わるだろうし、あの「要約」は原著に対する網羅度がかなり高いもので、権利面ではかなりグレーなものだったように思うから、閉鎖されるのは当然の成り行きだったと言える。が、自分の成長期にあたる年代にあのはてダがあったことは本当にキャリアの上で助けになったと感じているし、原著を所持していてもなおあのはてダを参照したいという思いがあるくらい、とても優れたものだった。他人の「きれいなノート」を借りて勉強していたような感覚というか、そんなような。「新人に読ませたい n 冊の本」というタイトルのクソ記事がもはや春先の業界の風物詩になっているが、そんな記事とは段違いにもっと直接的に本が持つ価値を訴えてくるコンテンツだったのだった、少なくともわたしにとっては。
図解界隈というのが流行っていると聞いて、そんなはてダがあったことを思い出した。結局のところ「SE 読みもの」も自己啓発本に他ならないし、個人的に DDD
なんて宗教だとすら思う。それにしても「要約」がきっかけで世界が広がるとことは実際あるかもしれないよ、ということが伝えたかった。
情報の一次ソースに当たることは昨今の情報社会において当然のことのように思うが、情報が氾濫している以上そうしなくても満足してしまうこともしばしば。
アプリケーション開発においても全くその通りで、QiitaやGitHubで拾ってきたサンプルコードがベストプラクティスと思い込んでしまう人がいる。
DDDだ、クリーンアーキテクチャーだ言い始める前に、エリック・エヴァンスやアンクルボブの本を手に取ろう。
そして会社やプロジェクトは情報の入手へ投資を惜しまないようにしよう。本を買おう。
「リポジトリは集約ルートのみ返す。1つの集約にはリポジトリは1つ。リポジトリの中でのみRDBへ問い合わせる。」って書いてあるけど、集約内の関連テーブルへの問い合わせをすべてリポジトリ書くから、リポジトリが巨大にならない？
DDDの実装例を見ているんだけど、参照はリポジトリ以外からも呼んでいてクソワロタ。
https://qiita.com/haazime/items/5776e4e25b6527b682e7
ActiveRecordのassosociationとRepositoryの相性って良くない気がする。(Repositoryのセオリーに完全に従うとassosociationが使えなくなるのでは？)
？「よし、AIだ」
？「よし、ディープラーニングだ」
？「よし、ブロックチェーンだ」
？「よし、DXだ」
？「よし、DDDだ」
共通して言えるのはアーキテクト不在の技術力ゼロ企業ほど、この傾向が強い
でも増田の言う通り、要所要所適度な加減で取り入れるのは賛成。ユビキタス言語とか、日本語使う我々が、更にSIerでもなければ何の意味もない。
過度な抽象というのは自分のDDDに対する理解と異なるな。どこまでを抽象化するかは触れていないはず。ユースケース層は必ずしも最上位レイヤーのみで収まる話ではないから、どこまでが抽象化の対象となるかはアプリケーションによる。
※追記あり。最後の追記は 2021/04/25 21:40頃※
タイトルの通りのことを思っているけど、顕名のブログで書くと社内で干されるので、増田に書く。社内の心理的安全性がそんなに低い訳ではないけども、潮流が凄いので今は慎重に振る舞いたい。
この記事を見て「キミはDDDのことを誤解している」と思われた方はコメント等で優しく（易しく、ではない）ご指摘願いたい。
※この記事では Web Application を前提とした話になっている。
短く言うならば「DDDの理念は取り入れるが実装は取り入れない」
夜中に投稿したのに多くの方に読んでもらえて嬉しく思います。コメントなどなどありがとうございます。以下、補足です。
あと、素晴らしい引用に感謝したいのですけれども、
「一般的に言えることだが、使っているフレームワークとは争わないこと。 フレームワークと対立してしまった時には、ドメイン駆動設計の基本を保ちながら、 詳細は捨て去る方法を模索すること。」エヴァンス本 p157
https://b.hatena.ne.jp/entry/4701728015809111618/comment/sonota88
例えば、アプリケーションのディレクトリ構造をDDDの用語に合わせたものにするという行為は、ここで言うところの「対立」に相当すると考えています。「基本」すなわち理念だけ存分に私たちのアプリケーションに取り込みたいものです。
少し違う角度の話をすると、初っ端からDDD前提のWAF(frameworkの方)を、できれば静的型付け言語で（←個人的な趣味）、新しく開発してそれを普及させることによって、当該WAFを学んだ人は自然とDDDも身に付いているという文化を作ることには熱い賛同の言葉を贈りたいと思っています。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
272あとで/1803users この本がスゴい！2020: わたしが知らないスゴ本は、きっとあなたが読んでいる
257あとで/1367users 鹿児島中央駅から新函館北斗駅まで新幹線の全駅に下車してきたので全力で紹介する_PR【駅メモ！】 | SPOT
247あとで/2110users ぼんくらITエンジニアでもYouTubeとスタサプでTOEIC 900点突破できたので勉強法をまとめていく - だいたいよくわからないブログ
235あとで/1299users 「イラストでわかるDockerとKubernetes」は完全に良書 - Cloud Penguins
222あとで/1463users 売れるアプリにするコツ100個書きます(吐血) - Crieit
203あとで/1011users JavaScriptの基礎知識をGIFアニメで分かりやすく解説 -総まとめ | コリス
192あとで/1373users もしあなたが急にAndroidアプリを業務で作るはめになった場合の選択肢(2021年初頭版) - Qiita
190あとで/959users OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
183あとで/1146users 一人前のプロマネってどんな人？ プロジェクトマネジメントのスキルセットとは-誰も教えてくれないプロマネのコツ | Mammoth Project
180あとで/1008users Pythonで仕事をする人のための書籍まとめ2021 - 学習, 業務効率化, アプリ開発からデータサイエンスまで - Lean Baseball
173あとで/1647users 【練習内容公開】イラストを100日練習しました｜都路 燕禅｜note
170あとで/2469users 僕のしょうもない人生を紹介します - いまトピ
170あとで/1019users 「フリーランス・副業向けサービス カオスマップ2020年完全版」が公開 - Digital Shift Times（デジタル シフト タイムズ） その変革に勇気と希望を
163あとで/1186users 9割の人が知らない再現性の危機 - 本しゃぶり
157あとで/1019users Mac を買ったら必ずやっておきたい初期設定を、全て自動化してみた | ulwlu | Zenn
154あとで/751users CTOの頭の中：技術投資を最適化する｜Shin Takeuchi｜note
152あとで/1503users 僕らはいつまでUSB Type-Cケーブルを選ぶのに迷うのだろう…もう間違えないための覚え書き - Magnolia Tech
148あとで/2347users 全財産を使って外車買ったら、えらいことになった｜岸田 奈美
141あとで/1040users 英語の発音について概説する - Amosapientiam
135あとで/648users 技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
131あとで/2088users Amazonで「鬼滅の刃」のコミックを買ってしまったのに、どうしても読み始める気になれない。 | Books&Apps
131あとで/1089users ステーキをおいしく焼く理論。料理家・樋口直哉が教える、肉の焼き方「新常識」【保存版】 - ソレドコ
129あとで/855users Webディレクターのスキルツリー - NMY
129あとで/915users Kubernetes 1.20からDockerが非推奨になる理由 - inductor's blog
126あとで/745users Web制作の時短に！2020年の便利オンラインツール・ベスト100選 - PhotoshopVIP
121あとで/880users 【総まとめ】2020年公開のすごいPhotoshopチュートリアル、作り方厳選まとめ - PhotoshopVIP
121あとで/613users ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
121あとで/864users 家で筋トレを続けるための簡単な「仕掛け」を取り入れてみたら、筋トレが楽しくなって習慣化した話 | Fun Pay! | あたらしい自分、はじめよう。楽天カード
120あとで/614users Micro Frontends Architecture Patterns | okmttdhr | Zenn
「仕事にしてしばらく経ったら大して好きでもなかったな」と「○○歳定年説」は、ベクトルが違う。
キャリアアップと言えば、手を動かす → 人を使う、の一択しかなかったから。
今は良い時代だ。
正直、アジャイルとかテストファーストとかDDDとか、どうでも良いと思ってる。
正直、真似事ですら、できるやつはあまりいない（定年説を唱えている界隈では）。
効率だ、品質だ、に、ふんづまったところで、大義名分は、ポンコツを除外できる とても良い言い訳になる。
少数で、歳は食ってるけど、その分、経験はあるやつと、経験は少なくても、知識に貪欲でパワーのあるやつだけでチームが構成できると、とても楽チン。
世の中にはプログラマー35歳定年説というものがあった。昔からそんなのはないという人と、あるという人がいた。40代も半ばになったときに「あぁ、これが35再定年説の根拠か」というものがなんかちらほら見えるようになってきたので書いてみようと思った。
世の中にはものすごいプログラマーというのはやっぱりいる。なんなら死ぬまでプログラミング書いていられるという人たちもいる（ブラック的な意味ではなく）。そんな彼らからしたらプログラマー35再定年説とか意味がわからない都市伝説にしか映らないだろう。
だが、普通に職業プログラマとして生きている俺のような人からすると、この35歳定年説はかなりの真実味を帯びている。
だが、そんな俺でも40代半ばまで延命できたのはやはり技術革新のおかげかもしれないが、結局平均寿命が伸びただけとも言えるだろう。
まず、技術に対する姿勢が変わる。正直言うとプログラミングとかもうしたくなくなる。というか、そもそも一生プログラミングを仕事にしたいと思う最初の頃は好きだと思っていたが、仕事にしてしばらく経ったら大して好きでもなかったな、と思うようになる。
大して好きでもないことを仕事にし続ける体力はやはり年とともになくなり、体力がなくなった分「自分が本質的にしたいと思うこと」が見えてくる。そしてそれはプログラミングではないため、ギャップがきつくなっていく。
おそらく、この辺が35歳くらいのあたりに来るのではないだろうか。35歳定年説と言ったら35歳ピッタリしか想像できないのが離散数学の世界で生きているプログラマらしいといえばらしいが。
そんな感じでやってても、20年もやればそれなりにスキルも身につく。さすがにGoogleの一線で働くような大天才たちと渡り合うことはできないが、もしかしたらGoogleの片隅で働ける程度のスキルはあるかもしれないが、正直もういいっす、っていう気持ちのほうが大きくなる。
次に、自分がどうにか身につけてきた知見というものがなかなか広まらない。コンセンサスが取れない、という状況にも苦しくなってくる。
自分がやってきたプロジェクトでこういうことをやったらうまく働いた、というような知見は共有するが、なかなか価値観が共有できないことに気がつく。若いうちは「だったら俺が全部やりますわ」くらいの気合を見せられたものだが、年を取ってくると「あ、そうですか・・・」となってしまう。純粋に体力も気力もなくなっていく。
プログラミングをやっているだけありみんな論理的な思考が大変上手だ。「皆さんホント論理的でいはりますなぁ」と言いたくなるわけだが、悲しいことに自分たちの振りかざす論理が、単なる正論、飛躍、極論、屁理屈、と言ったものであることに気づけない人も結構多い。こういうのを各個撃破するのも疲れる。
これからプログラミングを仕事にする人たちに言っておきたいことがある。もしこの世界で長く働きたい、定年までコード書いていたい、と思うなら、常に勉強をしなくてはならない。もしあなたがFラン出ているなら、他の人の倍努力しなくてはならない。できないならそこそこで転職したほうがいい。この世界にいるといかに若いうちの勉強が大事だったかを日々痛感する。
実務の上での俺の感じていることを書く。DDDだとかクリーンアーキテクチャだとかも大事だがもっとそれ以前に俺が根源的に重要だと考えているポイントだ。この辺をないがしろにしたらDDDもクリーンアーキテクチャも絶対に崩壊する。
まず、心得てほしいのはどんなにすごいプログラマでも意図の通じないコードは本当の意味で直せないということだ。
まず、引数チェック、状態チェックは必ずやれ。コードが語る、というようなことを言ってやらないやつが昔は多かったが、今もいるんだろうか。悲惨なバグやメンテナンス性の低下はそういった自分の意図の表明を横着したコードから起こり始める。「俺はこれをやる、だからこの機能を呼び出すならこういう状態にした上でこういう情報を渡せ、じゃないならやらない」とはっきり言え。もしこの辺を冗長だと考える同僚がいるならもう辞めたほうがいい。
引数チェックや状態チェックのコードで画面の半分が埋まったならそのコードは設計がおかしい。一旦手を止めてよく考えろ。一つの機能を動かすのにそんなに引数がいるのか、そんなにチェックする状態が多いのか、そしてそれらは本当に必要か検討しろ。
テストコードは絶対に書け。テストコードが書けない技術は絶対に使うな。意味のあるテストが書けないならやめたほうがいいという輩もいるが、とにかく意味があろうとなかろうと書け。引数にこれを入れたらこうなる、こういう状態でこういう事したらこうなる、というお前の意図はとにかく示せるだけ示せ。
だいたいこの辺を横着したやつは翌年酷く後悔するか、そこのメンテを担当した同僚を攻撃している。
コードが書けなくても大丈夫、という会社は、コードが書けたほうが有利な会社ではなく、本当にコードを書かない会社だというこは肝に銘じておけ。身につくスキルはEXCELの方眼紙を最低限の手数で作れるようになることか、本気でやればビジネスを理解できるかもしれないが、お前の技術者としてのキャリアはそこで止まる。
仮に憧れのスーパーハッカーがいる会社を目指しているとして、彼らがそこでどう働いているか、なにが泥臭いのかを想像できない、聞くことができないならやめておけ。浮かれ過ぎだ。
仮にGithubのURLを教えろという会社を目指しているとして、そこのリポジトリを飾り立てようと考えたならやめておけ、そういう会社はGithubにアウトプットすることを日常的な趣味として苦ではなくやり続けられる人を求めている。
年収をその会社の選択基準にしているならそこはおまえには分不相応な会社だからやめておけ。仮に入れたとしても馴染めることはまず無い。これは年収が低くても同じだ。
嫌いな人がいるならその会社はやめていい
コメントを観てこの「最小且つ単一の論理でなにか否定できた気になる」という輩への対処が一番疲れる
一晩立ってみたらこんなにブクマついててびっくりした。気になったブコメもあったのでちょっと追記しておく。
いきなり視点がミクロに、と言うやつなんだが、結局若いうちにこういうのできてないやつはあとで苦労するが、最初のうちは体力でカバーできている。体力でカバーできなくなったときに本当の意味でつけを払う羽目になるという意味で言ったり、あとオレみたいなおっさんが大変つらい思いをする、という意味でも言っている。
Fラン関係なくねっていうやつだが、昭和世代のステレオタイプかもしれない、ごめん。勉強する習慣もなければ大してやってきてもいないやつはこの業界だと倍苦労する羽目になるというふうに言いたかったと思う。どんな業界でもそうだとは思うが。
返す刀で結論づけしたがる人々がやっぱり現れるな、君たちはそう思わない人なんだろうし議論する気もないが何かしら言いたい人なんだろう。別にそれはそれでいいよ。お仕事頑張ってね。
「俺は大して辛くないけどなー」っていう人もやっぱり現れるな。辛くないんだったらいいことだと思う、お仕事頑張ってね。
4Kモニターでものすごく細かい文字を読んでいる若者を見た、という人、俺も同意する。もう見ていられないんだよね。
関白宣言っぽいな、というのは俺も思った。
結局の所、プログラマ35歳定年説は俺も打ち破りたいと思っていた口なんだが、打ち破れる人とそうでない人がいる、ということで、俺は後者だった、ということだ。当然50過ぎてもプログラマやっている人は見かけるので、数学的な真理というわけではなく、統計的な傾向なんだろうと思っている。
若いうちから、いい環境で働かないと、気持ちのほうがどこかで先にギブアップする。いくら大好きで転職だと思う仕事だとしても、体力や若さで捻じ曲げていることはなかなか気づかない。色んな本を読んで客観的な指標で判断したほうがいい。
遺言とか言って書いておいて追記したら俺はソンビか亡霊なんだろうか？
びっくりした。こんなおっさんの愚痴みたいなエントリーがこんなにブクマされるとは思ってなかった。いくつか気になったブコメがあったのでやはり書いてみたくなったので書く。
まず、この遺言を最後にいなくなるのかという話だが、おそらくいなくなる。ゾンビで居続ける体力ももはやない。
次の準備はすでにしている。それは俺が本質的にやりたかったことに近いことだと思うのをピックアップしている。
本質的にやりたかったことって何かという話なんだが、まず俺が感じるプログラマーという仕事は「良き作り手であり続けること」が根本的なモラルだと思っている。若手で右も左もわからないような状態でも、それこそやっとフィズバズが理解できたような状況でも今持っているレベルで最大限にできうる一番いいものを模索し続ける仕事だと思っている。初心者にはチェックコード書け、意図はできるだけ込めろというのはそういう意味でもある。これを真正面から受け止めてくれる職場を探したほうがいいというのは追加しておきたい。
プログラム論とかそういう話がしたいんじゃないということだけは言っておく。
俺も体力があるうちは良きつくり手を目指していたのだが、本質的にやりたいこと、もうちょっと言うなら、俺のモラルの軸は作ることにではなく使うことにあった。プログラミングというアクティビティを挟んでこっちにつくり手がいてあっちに使い手がいる。仕組みを理解して作るのがプログラマーなら、作ったプログラムを理解してよりよい日常を模索するのが使い手、と言ってもいいかもしれない。いいフィードバックループのあっちとこっち、と言ってもいいかもしれない。俺は「良き作りてが使ったものを使う良き使い手でいたい」ということに気づいたので、遺言を書くことにした。少なくともこれに気づいた時点でプログラマーとしての俺は死んだ。
まだ直感的なものでしか無いので、うまく言語化できていないのは申し訳ないんだが、今後10年位はそれを模索していくのではないだろうか。
全部誰かがやってるメールのやりとりを見て汲み取るだけ
この作業はどのようなことをするのか、どの部分を自分が担当するのか、どこに気をつけるのか、どのような部分を確認するのか、最終ゴールは何、そもそもこれは何
報連相は大事だ、何もわかりませんと言いたい。これは異常だと言いたい。
わからないことが多すぎる、正解は常に一つだけど、不正解は無限にある。
じゃあ最初から正解を上げておけば、不正解は正解に近いけど正解じゃない物だけになる。確認と訂正が楽になる。
大体みんながやる作業なんだったら、定型化してるはずだろ、ならマニュアルにできるだろ、なんでないんだよクソがクソクソ
作業をやった、死ぬほど確認と相談をした。俺が相談した人は聖人だった。80％ぐらい答えてくれたし、怒らなかった。
無視したり、逆ギレする奴もいるし、俺に対して「無能」のレッテルを貼って逃げようとする奴もいるからな、すごい怖いけど聞いてよかったよ
本当に助かった
でもここで何で俺が遜らなきゃダメなんだ？？？答えてくれた人はすごいありがたい。でも何で、そもそも俺が質問しなきゃいけないんだ？？
最初から情報が共有されてたら、いちいち答えてもらう必要も頭下げる必要もないんだが？？？
おかしいだろ、何で俺が胃をきゅっとさせながら申し訳なさそうに聞かなきゃならんのだ、業務の怠慢を末端に押し付けんなよ、部署はちゃんと仕事のやり方ぐらい残しておけよ
報連相をしたら、「やり方が悪い」なんて言われるだろう。
なんせ正解がどこにも書いてない問題について、正答を出そうとしたら沢山の疑問と答えが必要になるからな、yes/noクイズだよこれは。答える方からしたらしんどいわ
つーかしんどいって思うんならマニュアル作れよ、yes/noクイズは1発で正解すんのか？？しないだろバカだろ正解を渡せよバカ
俺が悪い以前に、俺に振る奴が悪い、やり方が悪い。
AはBBという仕事です。OOOやXXXをVVVするためにKKKと連携してCCCやDDDなどのチェックを行い、BBを完了させます。
とか具体的に言えばいいだろう？？言ったところでそこに書いてない部分の疑問は増えるからな、クソみたいなやりとり無限にしなきゃならんけどな
5W1Hとか、新人がめっっっっちゃくちゃ教えられてるが、できてないのは上司の方だったりしないか？？？
上司は、毎年教えられるのか？？？？5W1Hは新人以降に意識したことあるのか？？？？？？
マジでわかんねえ、何も知らされてねえ、何も共有されてねえ
「知らない」こと自体は数えられない。
「ここが分からない」になってようやく、知らないことを自覚して数えることができるんだわ
努力ベースの「個人が注意して」行う作業は無駄なんだわ、認識してなきゃ注意できないんだわ
今お前は「ハワイの気温は？」って聞かれる前に「ハワイの気温」について考えてたか？ちゃんと注意できてたか？
できないだろバカが、仕方がないんだよこれは、意識してる奴が「今からハワイの気温について聞くから」とか事前に共有することで、
ハワイの気温について調べたり把握したりする作業ができるんだわ
クソが
何も仕事ができねえ
