ビジネスニーズと設計

3177 ワード

ビジネスニーズ

サービスを開発する前に、どのような機能が開発できるかを整理する必要があります.
だから最初の要求事項を整理します.

会員。

- 회원은 가입하고 조회할 수 있음
- 회원은 일반과 vip 두가지 등급이 있다.
- 회원 데이터는 자체 db를 구축할 수 있고, 외부 시스템과 연동할 수 있다.(미확정)

注文および割引ポリシー

    - 회원은 상품을 주문할 수 있다. 
    - 회원 등급에 따라 할인 정책을 적용할 수 있다. 
    - 학인 정책은 모든 vip는 천원씩 할인해주는 고정금액 할인, 나중에 변경 가능
    - 할인 정책은 변경 가능성이 높다. 
    - 최악의 경우 적용하지 않을 수 있다.

要求から見ると、会員データ、割引政策などは現在決定しにくい.それでも、このような政策が制定されるまで待つわけにはいかない.
インタフェースを作成し、インプリメンテーションをいつでも交換できるように設計すればよい~~
現在、回転フレームは適用されません.

メンバードメイン設計

- 회원을 가입하고 조회할 수 있다.
- 회원은 일반과 vip 두가지 등급이 있다.
- 회원 데이터는 자체 DB를 구축할 수 있고, 외부시스템과도 연동할 수 있다.

メンバードメインのコラボレーション

企画者もこのような関係を見ることができます.これに基づいて、開発者はクラス図を作成します.

클라이언트가 회원 서비스로 가고 
회원 서비스는 회원 가입, 회원 조회 두가지 기능 가능
회원 저장소라는 인터페이스 만듦 (외부 데이터랑 연동할 수도 있으니까)
그리고 구현체를 세개 만든다.
- 메모리 회원 저장소, 
- 디비 회원 저장소, 
- 외부 시스템 연동 회원 저장소를 만들어
위에 세가지 중 무엇으로 할 지 정해지지 않았으니 제일 간단하게 메모리 회원 저장소를 이용하겠다. 그런데 메모리 회원 저장소는 컴퓨터를 껐다가 키면 다 사라진다. 

즉 역할과 구현을 나눈 방법이다.

会員等級図

インタフェースとインプリメンテーションを記録します.
これらは実際のサーバを実行せず、クラスを分析するしかないものです.

memberService 라는 역할을 만들고,  구현 클래스로 memberServiceimpl 를 만든다.

memberRepository 라는 역할을 만들고, 구현 클래스로 memoryMemberRepository,
DbmemberRepository 를 만든다.

위에 대로 코딩하면 된다.

しかし、実施形態(M e m o r y M e mberRepository,DbmemberRepository)
クラスグラフしかないのでnewで決めます
判断が難しいので、対象図を作成しました.

メンバー・オブジェクトのグラフ

クライアントは、実際のインスタンス間の参照を記録します.

会員サービス:MemberServiceImpl

オブジェクト間のメモリリファレンスプロシージャ.

メンバードメイン設計における問題

このコードは設計上どんな問題がありますか?
他のリポジトリに変更する場合、ocpの原則を遵守しますか?
DIPをちゃんと守っているのかな?
依存関係はインタフェースだけでなく,実装にも依存するという問題がある.
注文が終わったら、問題と解決策を説明します.

オーダーと割引ドメインの設計

受注の生成:クライアントは受注サービスに受注の生成を要求します.
会員照会:割引には会員等級が必要です.したがって、注文サービスは会員リポジトリで会員を検索します.
適用割引:注文サービスは会員等級に基づいて割引政策を授権します.
受注結果の戻し:受注サービスは、割引を含む受注結果を返します.
実際には、受注データをデバイスに保存しますが、例が複雑になる可能性があるため、受注結果を省略して返すことができます.