そんなに難しい本じゃないんだから、元の本を読むべきだと思っている。劣化したアイディアの再生産より、実践してどうなったかを書いてほしい
同心円の図に囚われて階層を厳密に作りすぎる「クリーンアーキテクチャ病」の人に最適。本質は依存の方向を業務ルールに向けること、に尽きる
絶対に3行書かずにクソ長い前置きでクッション稼ぎしてるんやろな〜と思って見てその通りだった。不誠実
3行で説明したことの説明が必要なら嘘じゃない。誰かの有用になれば良いね。
"業務的な関心ごとを中心に考えよう" "業務的な文脈や技術的な都合が混ざらないように境界を分けよう" "データベースやUIなどの具体的な技術は、いつでも差し替えられるようにしよう"
DDD とクリーンアーキテクチャの説明が混ざってる。Entity（集約）がないとドメインモデルを表現できないし、インターフェースによる抽象化の部分は間違ってるか、意味がわからない。
シャープMZ・X1シリーズ
「Buzzwordによる設計」 https://koriym.github.io/blog/2026/03/25/design-by-buzzword/ だいたい提唱者は嘆いてるの草。／差し替える必要性という前提は間違っていると思う。
ソフトウェア設計の結合バランスって本を読め 話はそれからだ
『例の同心円の図は一旦忘れよう』
長いかな？よくまとまってる。
モジュールはhumbleに作れと本書に書いてあって、「機能を廃止する際にそのモジュールを削除するだけでほぼ仕事が終わるのがよい」みたいな内容に感心した記憶。アダプターパターンはあまり同意できなかった
Entity はお客さんとか個々に区別する必要があり連続性がある（だいたい永続化が必要）存在という意味であってJava用語ではないしEntityに対する業務があるのであってEntityのない業務は妄想かなんかだ。
『クリーンコンピュータ』（MZ、CZシリーズ）を言及している人が居たので満足です。
結局DDDもCAも、経験を通して課題意識を持ち、分析や解消をしてみようとしないと理解できないってのが最大のハードルだと思う。なので分かりやすく解説には限界がある
3行の記事を期待したのに
これを実践しようとしたら、抽象化とDI を伴うレイヤードアーキテクチャの類いが必要になるのでは
1行は2万文字とする。
クリーンアーキテクチャを3行で説明してみる
そんなに難しい本じゃないんだから、元の本を読むべきだと思っている。劣化したアイディアの再生産より、実践してどうなったかを書いてほしい
同心円の図に囚われて階層を厳密に作りすぎる「クリーンアーキテクチャ病」の人に最適。本質は依存の方向を業務ルールに向けること、に尽きる
絶対に3行書かずにクソ長い前置きでクッション稼ぎしてるんやろな〜と思って見てその通りだった。不誠実
3行で説明したことの説明が必要なら嘘じゃない。誰かの有用になれば良いね。
"業務的な関心ごとを中心に考えよう" "業務的な文脈や技術的な都合が混ざらないように境界を分けよう" "データベースやUIなどの具体的な技術は、いつでも差し替えられるようにしよう"
DDD とクリーンアーキテクチャの説明が混ざってる。Entity（集約）がないとドメインモデルを表現できないし、インターフェースによる抽象化の部分は間違ってるか、意味がわからない。
シャープMZ・X1シリーズ
「Buzzwordによる設計」 https://koriym.github.io/blog/2026/03/25/design-by-buzzword/ だいたい提唱者は嘆いてるの草。／差し替える必要性という前提は間違っていると思う。
ソフトウェア設計の結合バランスって本を読め 話はそれからだ
『例の同心円の図は一旦忘れよう』
長いかな？よくまとまってる。
モジュールはhumbleに作れと本書に書いてあって、「機能を廃止する際にそのモジュールを削除するだけでほぼ仕事が終わるのがよい」みたいな内容に感心した記憶。アダプターパターンはあまり同意できなかった
Entity はお客さんとか個々に区別する必要があり連続性がある（だいたい永続化が必要）存在という意味であってJava用語ではないしEntityに対する業務があるのであってEntityのない業務は妄想かなんかだ。
『クリーンコンピュータ』（MZ、CZシリーズ）を言及している人が居たので満足です。
結局DDDもCAも、経験を通して課題意識を持ち、分析や解消をしてみようとしないと理解できないってのが最大のハードルだと思う。なので分かりやすく解説には限界がある
3行の記事を期待したのに
これを実践しようとしたら、抽象化とDI を伴うレイヤードアーキテクチャの類いが必要になるのでは
1行は2万文字とする。