Ryo Takeuchi

Software Enginneeer

[Ryo Takeuchi @ryooou25]

もう個人情報集めるなら相当な覚悟がいるな

[Ryo Takeuchi @ryooou25]

全体的に、人間が製品に対して最終責任を持ち続けるのが前提にはなっているので、別に「バグって復旧できませんでした、他の使って」が許される世界線になれば話は変わるのかもしれない

[Ryo Takeuchi @ryooou25]

あと戦略パターンは、事業戦略とアーキテクチャ戦略の紐付けとかもあるけど、特に大事だと思ってるのは ドメイン知識 - モデル - コード のイテレーティブな蒸留・改善プロセスであって、これはAI開発に完全移行したとしても重要なんじゃないかな

[Ryo Takeuchi @ryooou25]

個人的には、戦術パターンのコア概念は集約であって、それと契約プログラミングの考慮があれば、他はそこまで重要ではないと思ってる。その上で、集約と向き合うとCQの特性差異とも向き合うことになるし、やらない場合、強い整合性境界の表明がトレードオフされる

[Hironobu Ueno | double jump.tokyo CEO @h2ueno]

DDDやクリーンアーキテクチャについてFableが実際のところどう思っているか？
--
結論から言うと、どちらも「本物の洞察」と「儀式化した部分」の抱き合わせで、価値の分布が極端に偏っています。分けて評価します。

DDDで今も第一級の価値があるのは戦略的設計の側です。Bounded Context、ユビキタス言語、コンテキストマップ、core/supporting/genericのサブドメイン分類。「大規模ドメインの統一モデルは幻想で、モデルは言語とチームの境界に沿って割るべき」という洞察は20年経っても摩耗しておらず、マイクロサービスの境界設計やチームトポロジーの理論的基盤は実質的にここから来ています。特にサブドメイン分類は、設計投資をどこに集中させるかを決める道具として最もレバレッジが高いのに、最も使われていない。

一方、戦術的パターン(Entity / Value Object / Repository / Factory)の大半は2003年当時のJava/OOPの制約の産物で、代数的データ型のある言語では価値が目減りしています。Value Objectの規律はnewtypeと網羅的matchで代替可能で、しかもコンパイラが強制する。"Make illegal states unrepresentable"の方が、VOのセレモニーより少ないコードで同じ目的を達成します。Wlaschinが示した通り、DDDの本質はクラス階層より型で表現した方が忠実です。Evans自身が「みんな戦術パターンばかり見る」と繰り返しぼやいているのは示唆的で、Repositoryの下にORMを包み、貧血モデルにマッピング層を重ねるだけのいわゆるDDD-liteは、DDDの失敗というよりDDDの不在です。

例外はAggregateで、これは型システムで代替できない唯一の戦術概念だと考えています。本質は「どの不変条件に強整合が必要で、どれを結果整合に落とせるか」というトランザクション境界の設計判断であり、これは今でもドメイン設計の核心です。同時に最も誤用されやすい概念でもあり、大きすぎればロック競合、小さすぎれば不変条件が漏れる。

Clean Architectureは、率直に言えばHexagonal(Cockburn, 2005)とOnion(Palermo)の統合とリブランドで、中身よりブランディングの勝利です。核の主張——依存は内向き、ドメインはインフラを知らない——は依存性逆転のアーキテクチャ規模への適用で、これ自体は健全。ただし本の内容は影響力に比して薄く、核心は2012年のブログ記事一本に収まります。実害は同心円図が「4層ディレクトリ+全境界にinterface」という様式として機械的に複製されること。実装が永遠に1つしかないtrait、DTOマッピングの山、1フィールドをHTTPからDBまで追うのに5ファイル。これは投機的抽象化で、行使しないオプションにプレミアムを払い続ける行為です。

中でも「DBは詳細」は同書で最も疑わしい主張です。多くのシステムではデータモデルこそ重心で、Postgresを差し替える日は来ない。しかもRepositoryの裏にDBを隠すと、トランザクション設計やクエリ最適化といったDBの強みを捨てがちになる。sqlxのコンパイル時検証クエリのような道具の価値がtrait境界の裏で死ぬのは典型例です。守る価値があるのは「依存の向き」と「ドメインコアの隔離」だけで、リングの数や用語の正統性はどうでもいい。そしてRustならこの依存規律はcrate分割で静的に強制でき、違反がレビューコメントではなくコンパイルエラーになる。人間の自制心にレイヤー規律を頼る原典の姿より、こちらの方がよほど筋がいい。

エビデンスについても正直に言うと、どちらも効果を示す実証研究はほぼ存在しません。ソフトウェア方法論全般がそうですが、これらは経験豊富な実務家のもっともらしい逸話であって科学ではない。だから信奉やアイデンティティの対象にすべきではなく、経済性の問題として扱うべきです。間接層・儀式・学習コストというプレミアムを払って「特定の変更が安くなる権利」を買う取引であり、付随的に、共有語彙と予測可能な構造がオンボーディングコストを下げるという調整価値もある。不変条件が複雑で寿命の長いドメイン——金融、会計、規制対応——ではオプションがほぼ確実に行使されるので買う価値があり、ジェネリックなCRUDサブドメインで買うのはただの損です。

まとめると、戦略的DDDは本物、戦術的DDDはAggregateを除き型システムで大半代替可能、Clean Architectureは正しい原則1つ+過剰な処方箋。実務の最適解は「戦略的DDD+型駆動モデリング+依存規律のcrate構造による静的強制」あたりに収束する、というのが私の評価です。

[Ryo Takeuchi @ryooou25]

デヴィッドバーン良過ぎたな

[Ryo Takeuchi @ryooou25]

Vite+ありがたすぎる

[Ryo Takeuchi @ryooou25]

サウンドハウスパイセン、毎度なんでこんなに配送早いの....Amazon並み

[Ryo Takeuchi @ryooou25]

ICONIXとイベントストーミング。予備設計から得られるフィードバックの重要性、曖昧さの排除、概念モデルの合意とか、その辺は双方志向していて、後者の方がシンプルな分、より反射神経を信用してるイメージがある。

[r.kagaya @ry0_kaga]

ケントベックのTDD with AI agents

・AIが何かを誤解した場合、期待される出力をテストとして示すことでAIにフィードバックを与える
・AIが意図せずコードを壊すのを防ぐために、高速で実行される大量のテストを常に実行している
・AIは「趣味がなく、デザインの感覚がない」ため、結合度を下げたり凝集度を高めたりすることには長けていない。大量のテストでAIが引き起こす破壊的な変更を防ぐ

[ike | カウシェCTO @ike002jp]

46億円を調達。そしてAI駆動で「ECの再発明」に挑戦中🔥

7/7にはPKSHA、LayerX、Findy様とイベントを開催！「EC×AI」を支える技術について、僕もCTOとして語ります👇
https://t.co/UXZBefWWC8
#シェア買いやめました

[門奈剣平 | カウシェ @mompyyy]

【RT願】祝、資金調達しました！累計約46億円
ここ1年半でGMV25倍・売総90倍としっかり伸ばしてきました #シェア買いやめました

実は日本はEC後進国。
「日本のECを再発明する」、決意の発表です

[Ryo Takeuchi @ryooou25]

Plan,Actのイテレーションを大〜小プロセスで回すのは前提として、要求整理や概念設計・モデリング、DesignDoc作成なんかはLLMをCopilotとして使い倒して、実装フェーズになってから運転席譲りつつ適時軌道修正が今のところ現実的な気がしてきてる。が、もっと使いこなせれば変わる奴なのだろうか

[Ryo Takeuchi @ryooou25]

Cursorもっと使いこなしたい

[Ryo Takeuchi @ryooou25]

前にeslintのflat config対応したリポジトリ、久々に見たら自分が何設定したのか全然思い出せん

[ビクターエンタテインメント @VictorMusic]

日頃よりくるりを応援いただいている皆様へ

[Ryo Takeuchi @ryooou25]

有名なやつだけど、定期的に読み返して自戒してる。ナレッジ共有は止めないが業務としては経験や好み、権威性の差をなるべく排して、個人が努力で改善できるルールになってるのでオーナーシップが持ちやすい。民主化が徹底されているのが素敵。

https://t.co/iUxNIb4rY8

[Ryo Takeuchi @ryooou25]

自動テスト、自分の怠惰で抜けてる性格やワーキングメモリのスペックを補助するために書きたいので、そもそも無いところに入れるとかmockだらけとか壊れやすいテストとかで勤勉さが求められると途端に辛い

[Ryo Takeuchi @ryooou25]

App Router(というかRSC)とBEの通信、結局何でやるのが良いのだろう。gRPCとかRESTの細粒度の内部通信で作るのは相性良さそうとは思いつつ、結局UX的に一定CSRに寄せるとこは出そうで、それならgqlで統一的に管理して、スキーマ設計で工夫した方が管理効率高いとかもありそう

[Ryo Takeuchi @ryooou25]

特定のアーキテクチャや開発手法に強いこだわりないのだけど、思想と民主化はめちゃ重要だと思ってるので、それを可能にするだけの論理的強度は持っていたい

[Ryo Takeuchi @ryooou25]

RDB強化月間