DjangoでWebアプリを作ってみる。【vol. 11 学生用のレポート共有Webアプリを作ってみた。】 - Qiita
イントロダクション ６月あたりにDjangoもそもそもPythonも今まで触ったことないけど、どんなもんだろうと実装していました。そんな折に、ちょうど知り合いから「学生用のレポート共有Webアプリが欲しい」的な話をいただいたので、１ヶ月ほど集中して作ってみました。 リリースはまだ先でこれからもデザイン調整や項目変更はありそうなのですが、概ね完成した段階なので、ここらでまとめてみたいと思います。今回、ReadMeに記載していますように、非常に多くの記事やブログに助けられました。感謝の意味も込めて以下記載となります。 機能構成 管理者向け機能 認証 ログインURLリクエスト ログイン ログアウト レポートメンテナンス 検索 ソート ページング レポート登録 レポート削除 レポートダウンロード ユーザーメンテナンス 検索 ソート ページング ユーザー登録 ユーザー更新 ユーザー削除 アクセスログ
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
Python におけるドメイン駆動設計(戦術面)の勘どころ
おすすめ書籍 エリック・エヴァンスのドメイン駆動設計 (2011) “Domain DrivenDesign” Eric Evans (2003) DDD 信者の聖書。その難解さから「鈍器」と呼ばれる。抽象度が高く、分厚いので 読み通すの大変だが、何回読んでも発見がある。ここで整理されている概念は、 10 年以上経った今も色褪せない。 実践ドメイン駆動設計 (2015) “Implementing Domain Driven Design” Vaughn Vernon (2011) Evans 本の中身は本質を突いているが、その実践は容易でない。本書は、 Evans 本以降の10年間に発表された新しい開発技法を取り込みながら、 DDD の考え方 を実践に移すにはどうすれば良いかを記述した指南書。 ※ 読むのに挫折しても、鈍器としてなら使えます ※ ※ 翻訳レビューに参加しました。
中規模Djangoアプリケーションのモジュール構成 - thara.dev
DjangoやRuby on Railsといったフルスタックフレームワークは、シンプルなCRUDアプリケーションを素早く構築することができるが、複雑なアプリケーションの設計をどうすればよいかという問題にはいつも悩まされる。 どのようなプロジェクトによるかはケースバイケースだが、自分の中でおおよそ固まってきたので、それをまとめてみる。 Djangoの場合、フレームワークが必要とするモジュールはsettings.pyとmodels.pyぐらいなので、各Djangoアプリケーション内では割と自由にモジュールを定義できる。 自分は以下のような自作モジュールを配置するようにしている。 commands query services utils commands まずは、command。このcommandはGoFのCommandパターンのことではなく、Command-Query Responsibil
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bitbucket
GitHub - ledmonster/ddd-python-inject: DDD, CQRS and Hexagonal Architecture example using inject package
