気に入った記事をブックマーク
- 気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
- 記事を読んだ感想やメモを書き残せます
- 非公開でブックマークすることもできます
エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント7件
- 注目コメント
- 新着コメント
pmint
"utilsレイヤー"はレイヤーじゃないだろ。オニオンアーキテクチャもクリーンアーキテクチャも実装するとMVCになっちゃう謎。目立ちたいだけの人たちが考えた車輪の再発明。鵜呑みにするだけの知識レベルはそう高くない
rarirurero9999
アーキテクチャの話とDDDの話は分けて考えたいなぁって気持ち。もちろん大半は直接繋がってると思うけど、運用しながら改善していく強い意志がのほうが大事で、その意思をメンバー全員に波及させる方が大変かも？
turanukimaru
ドメインサービスが欲しくなるのはドメインモデル（Aggregation）が貧弱だから。あとEntityを外に移すときにDTOに詰め替えてないだろうね？操作可能なモデル自体を渡さないとUsecaseが操作ロジックを書くはめになる。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
いまの話題をアプリでチェック！
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
バックエンドTypeScriptでオニオンアーキテクチャを運用してわかった手応えと反省点
弊社ではT3-Turboを導入しており、フロントエンドにNext.js、サーバーサイドにNestJSを採用しています。... 弊社ではT3-Turboを導入しており、フロントエンドにNext.js、サーバーサイドにNestJSを採用しています。 本記事では特にサーバーサイドのアーキテクチャに焦点を当て、私たちが実践しているドメイン駆動設計（DDD）について、その運用から見えてきたメリット、デメリット、そして今後の課題を考察・共有します。 1. アーキテクチャの全体像 弊社ではDDDの実現方法としてオニオンアーキテクチャを採用しています。 クリーンアーキテクチャではなくオニオンアーキテクチャを選択した理由は、後者の方が usecase（アプリケーション層）と domain（ドメイン層）の境界がより明確 であり、「ビジネスの関心事をドメインとして独立させる」という私たちの設計思想と強く合致したためです。特に、オニオンアーキテクチャがドメイン層からアプリケーション層への依存を許さないという原則は、私たちが目指すドメイン
ブックマークしたユーザー
すべてのユーザーの
詳細を表示します
詳細を表示します
2025/09/12 リンク