コードの実装から理解するDDDとNot DDD - Qiita
はじめに DDDとは？という議論が尽きません。 「レイヤードアーキテクチャ、Repositoryなどは軽量DDDでありDDDではない」 「ユビキタス言語に基づいたドメインモデリングこそDDDの本質である」 とは言うものの、レイヤードアーキテクチャから先行して理解することが多いのが実情です。 なぜドメインモデリングの導入が進まないことが多いのか考えてみると、初学者にはドメインモデリングを実施したときの最終的な実装とそうでないときの実装の差がわかりづらく、どのような価値があるのかがわかりづらいためだと思います。 「ドメインモデリングをしたからドメインが素晴らしく良い実装になった」という例を紹介できればいいのですが、なかなか適切な具体的な例で説明することが難しいです。 そこでモデリングよりも技術的な視点にはなってしまいますが「集約を意識したDDDな実装とDDDではない実装」を具体的に紹介すること
リーダブルアーキテクチャ - usecaseにおける時間軸と抽象度の統一 - Qiita
はじめに Clean Architectureやレイヤードアーキテクチャでは、どのようにレイヤーを定義するかついては言及されています。 そのような中usecase(レイヤードアーキテクチャではApplication層)をどのように実装するべきかについての議論は少ないです。 しかし私はリーダブルなアーキテクチャを実現するために、一番大切なことはusecaseを適切に実装することであると考えています。 そこでusecaseを実装する上で起こりがちな抽象度の問題を例に、リーダブルなアーキテクチャを考えいていきたいと思います。 サンプル 1:1のチャットアプリでUserとWorkerが存在して会話ができるアプリを例にあげます。 以下の図では青い背景はinfraの関数実行、緑色の背景はdomainの関数実行、赤い背景はusecaseの関数実行を示しています。 usecaseのCreateChat関数
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
