DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
オブジェクト指向で、データモデルを生成するクラスにはどんな名前をつけるべき？
オブジェクト指向の初学者です。データモデル？を生成するクラスの命名に困っています。 以下のような、モデルの生成・編集・削除などをするクラスのことはオブジェクト指向ではなんと呼ぶのでしょうか？また、こうしたオブジェクト指向のクラスの責任の分け方を学ぶためには何を参照するのがよいでしょうか。 # このクラスが"データモデル"です。 Class User(): self.name = "" self.age = 0 # このクラスの命名に悩んでいます。 Class UserFromDatabase(): self.db = DBClient() def make_user(): data = self.db.create({table: "user"}) return User(data) def get_user(id): data = self.db.get({table: "user",
Webアプリケーションの設計パターン / fujimisakari blog
Webアプリケーションを開発する上での設計パターンついて ある程度自分の中で知見がまとまったのでつらつら書いてみる。 ここで指してる設計パターンが何なのかというと、 機能を開発するための業務ロジック設計ではなく システム全体の構造の大枠を定義するための設計パターンになります。 なぜ設計が必要なのか設計方針を決めないまま開発していると、個々それぞれの実装経験やドメイン知識などが異なるので スキルに応じたフリーライティングとなり実装パターンがバラつきコードの可読性や保守性が下ってきてます。 これを防ぐために、システム構造の大枠の設計を定義します。 設計を導入することにより、どの機能はどこの書けばよいのかが明確になるので 誰が実装してもある程度同様の実装方針となります。 また、局所的な視点から見て不恰好なコードがあっても、 全体的な視点から見ればコードのレイアウトがきれいに整った構造になるので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bitbucket
Diagrams · Diagram as Code
system-design-primer#system-design-interview-questions-with-solutions
