[pre onboarding]最初の課題研究


  • 回目の任務を完成し、不足点を埋める.
  • プロジェクトの構造はdjangoのプロジェクト構造に従う.
  • 4のアプリケーションを使用します.
  • 掲示板:掲示板プロジェクトの具体的な設定ファイルと、各アプリケーションへのルーティングを要求する役割を担当します.
  • メンバー:フォーラムメンバーへのリクエストを処理します.
  • post:投稿に対する操作要求を処理します.
  • セキュリティ:認証および認可に関連する要求を処理します.
  • 投稿登録機能分析コード
  • を使用
    # 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

  • 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