[pre onboarding]最初の課題研究
第回目の任務を完成し、不足点を埋める. プロジェクトの構造はdjangoのプロジェクト構造に従う. 4のアプリケーションを使用します. 掲示板:掲示板プロジェクトの具体的な設定ファイルと、各アプリケーションへのルーティングを要求する役割を担当します. メンバー:フォーラムメンバーへのリクエストを処理します. post:投稿に対する操作要求を処理します. セキュリティ:認証および認可に関連する要求を処理します. 投稿登録機能分析コード を使用 CQRSはCommand Query Responsibility Segregationの略で、文字通り解釈すれば「コマンドクエリ責任分離」となります.CommandとQueryは分離されています.これはアプリケーションを構成するアーキテクチャのモデルです.つまり、CQRSは、アプリケーションの実装時にコマンドとクエリーの役割を分離します. は、通常、接続されたデータベースにデータを記録として作成、参照、更新、または削除する.張兄ormのようにまた,データを記録として格納する過程で,データは特定のモデルで処理される.これらのモデルは、クエリー/更新/削除のために、初期の用途とは異なるレコードを格納できます.そうすると、そのモデルはそのままデータACEに格納されます.これにより、1つのモデルが異なるニーズを満たすために膨大になるか、最初とは異なるモデルになる可能性があります. ですので、このモデルを再加工する必要があります.モデルが変化するにつれて、実際にデータを格納、更新、削除するモデルとクエリーで使用するモデルの間に差があります.したがって、開発者は、1つのデータの格納、更新、削除のコマンド部分と、クエリーで使用されるクエリー部分のモデルを別々に管理します.これがCQRSが現れた背景です. CQRSモードは他のモードと同様に、いかなる問題を解決する方法である.したがって、CQRSモードは適用しなければならないモードではない可能性がある.現在、多くのアプリケーションはCRUDアーキテクチャに適しており、CQRSは使用されていません.また,CQRSモードは容易に実装できるモードではなく,不要なシステム複雑さをもたらす可能性がある.たとえば、モデルの適切な境界を区別するために、ドメインをDDDメソッドでモデリングする必要があります. は、最終的に、コマンドとクエリーの責任を個別のアプリケーションから完全に分離することができる. 注意:https://always-kimkim.tistory.com/entry/cqrs-pattern
# dto/post_content.py 데이터베이스만 담당해주는 곳
from dataclasses import dataclass
@dataclass # 데코레이터를 클래스 위에 붙여준다. 이는 데이터 클래스를 보다 용이하게 선언해주는 데코레이터.
class PostContents: # 이 클래스가 밑에서 views.py, serives.py에서 db가 필요할 때마다 불려질 것.
title: str
category: str
content: str
# views.py : 내 생각엔 여기는 전체적인 명세표 같다. 어디서 데이터 가져와서 어디에 담고 무슨 기능을 구현할 지 설명해주는 느낌
class PostView(View):
def __init__(self, **kwargs):
super().__init__(**kwargs)
self.post_service = PostService()
@authorize
def post(self, request, member):
data = json.loads(request.body) # json으로 데이터 받아오기
post_contents = PostContents(**data) # dto에 있는 데이터들 post_contents 변수에 담고
self.post_service.write(post_contents, member) # service.py에 있는 post_service 클래스의 write 메소드를 부르고 거기에 dto에서 가져온 post_contents와 멤버를 게시글에 등록할 것.
return JsonResponse(data={}, status=HTTPStatus.CREATED) # 리턴값으로 HTTPStatus.CREATED 반환
# service.py : 여기서 로직을 담당
class PostService: # 클래스 만들고
def write(self, contents: PostContents, author: Member): #write라는 메쏘드에 dto에서 만든 PostContents 담아주고 member 앱에 있는 Member 파라미터로 받기
new_posting = Posting(
member=author,
title=contents.title,
content=contents.content
) # new_posting이라는 변수에 Posting을 담을 건데, 그 안에는 게시물 쓰기에 필요한 내용들, member, title, content가 들어감.
Posting.add(new_posting) # model에 있는 Posting에 new_posting을 추가시켜줄거야!!
# models.py
class Posting(Document): # Posting이라는 클래스 만들어주고 mongoengine에서 지원하는 Document를 상속받음
id = IntField(primary_key=True)
member = ReferenceField(Member)
title = StringField(max_length=100)
content = StringField(max_length=500)
created_at = DateTimeField(default=datetime.utcnow)
updated_at = DateTimeField(default=datetime.utcnow)
comments = ListField(Comment)
hits = IntField(default=0)
category = StringField(max_length=50)
hit_members = ListField(Member)
# 필요한 컬럼들을 mongodb에서 원하는 타입으로 넣어줌. 신기한게 referenceField(Member)하면 ForeignKey 기능이 됨.
meta = {'collection': 'postings'} # meta를 써서 postings라는 테이블을 만들어줌.
🪓 その他:CQRS
Reference
この問題について([pre onboarding]最初の課題研究), 我々は、より多くの情報をここで見つけました https://velog.io/@majaeh43/preonboarding-1차-과제-studyテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol