필드 구동 개발은 무엇입니까

5419 단어 DDD

개시하다


올해 가장 힘들었던 일로.
"역구동 개발을 설명할 수 없습니다."
그래서 도메인 이름 구동의 개발을 총괄하고 싶습니다.

무엇이 역구동 개발입니까?


역구동 설계를 바탕으로 조정 개발을 한다는 뜻이다.

도메인 구동 설계란?


Domain Driven Design(Domain Driven Design)
간단하게 정리를 해볼게요.
역 지식을 바탕으로 각 역에 모델을 만드는 디자인 방법.
장점
• 각 분야는 독립된 형식으로 방대한 프로젝트의 복잡성을 제거하고 유지보수와 운용에 편리하다.
· 지역 전문가와 개발자 간의 소통이 원활해지다.
※ 도메인 전문가란 해당 분야에 정통한 사람을 말합니다.예) 직원 데이터의 분야 전문가는 인사부다.

도메인 이름은 무엇입니까?


domain
주된 의의
영지, 영토, (지식, 사상, 활동 등) 영역, 영역,...계, (토지의) 완전 소유권
각 전공과 서비스의 담당 분야를 바탕으로 설계를 하겠다는 건가요?

도메인 드라이버


이것은 단지 내가 생각해 낸 절차일 뿐, 단지 참고로 제공할 뿐이다.

1. 이야기 줄거리를 생각한다


  • 뭘 하고 싶어요?
    예) 알림 애플리케이션을 만들고 싶습니다
  • .

  • 이야기를 고려하다
    디자인의 단계가 아니기 때문에 사용자의 각도에서 써야 한다.
    예제)
    사용자 관점에서 고려하다.
    1. 로그인해서 다른 사람이 자신을 알게 한다.
    2. 일람표에서 리마인드를 볼 수 있다.
    3. 필요한 알림을 새로 만듭니다.
    4. 알림 표시줄에 연월일 시간, 제목, 비고 표시줄과 라벨을 달았으면 합니다.
    5. 보고 싶은 리마 인덱스를 검색한다.
    6. 알림을 수정합니다.연월일 무렵, 제목, 비고란, 라벨을 수정하고 검사를 완료할 수 있습니다.
    7. 리마인드를 제거할 수 있다.
    8.태그를 추가할 수 있습니다.라벨에 색과 제목이 추가되었다.
    9. 태그를 편집할 수 있습니다.
    9.태그는 삭제할 수 있습니다.
    10. 등록 후 년월일이 되면 안드로이드에 알립니다.
  • 2. 범용 언어 만들기


    범재 언어: 팀 전체(역 전문가와 개발자)의 공통 언어.
  • 설계할 시스템 영역에 나타나는 용어의 명칭과 동작을 자유롭게 쓴다.
  • 용어집을 만들어 용어에 의미를 정의합니다.그 밖에 각 영역과 관련된 용어를 검사한다.
  • ※ 이후에는 필요 없지만, 여기에 쓰여있지 않은 것은 코드에도 존재하지 않습니다.
    ※ 필요하면 언제든지 추가됩니다.추가하려면 역전문가와 논의해 정말 필요한지, 같은 것이 있는지 확인하고 추가한다.
    예제)
    로그인: 사용자가 식별하는 곳
    사용자: 응용 프로그램 사용자
    알림: 지정한 날짜 내에 통지하고 싶은 내용이 있습니다.연월일 무렵, 제목, 비고란, 라벨, 검사 완료.
    알림 목록: 현재 등록된 알림을 볼 수 있습니다
    년 월 일 시간: 알림기에 등록할 알림 날짜와 시간.yyyMMddhmm(예: 20201219)로 구성되어 있습니다.
    검사 완료: 알림기에 등록된 스위치입니다.통지해야 할 경우 True(ON)는 통지하지 않거나 완료되면 False(OFF)를 할 수 있습니다.
    태그: 분류 알림.색상과 제목이 있습니다.
    알림: 각 알림기의 연월일이 해당 시간에 도착하면 로그인한 제목을 안드로이드 프로그램의 알림 기능으로 표시하고 사용자에게 알립니다.

    3. 공통 언어에 따른 도메인 정의


    원시 도메인 이름의 뜻은 영역이다.구역
    DDD의 도메인은 다음과 같이 정의됩니다.
    -역: 팀워크의 전체 업무 프레임워크.
    또한 도메인에는 세 가지 도메인이 있습니다.
    - 핵심 도메인: 비즈니스에서 가장 중요하고 전략적으로 필수적입니다.최우선.
    - 보조 서브 도메인: 비즈니스에서는 특별하지만 핵심 도메인보다 우선합니다.
    (외부 지원 항목, 외부 도구 등)
    - 공통 하위 도메인: 특별하지는 않지만 시스템에서 필요합니다.
    (모든 시스템에 필요함)
    예) 2에서 제시한 범용 언어를 쓰고 영역으로 분할한다.
    - 핵심 영역: 이번 응용 프로그램의 경우 원격 인코더를 관리하는 부분은 핵심에 속하기 때문에 원격 인코더 관리와 관련된 내용
    - 보조 하위 도메인: 외부 알림 애플리케이션을 지원하는 알림
    - 유니버설 서브도메인: 사용자가 관리하는 로그인 업무는 시스템에 필요하기 때문에 여기.

    4. 컨텍스트 맵 작성


    경계 상하문: 경계를 구분하여 상하문 단위로 간단하게 구역을 관리할 수 있다.컨텍스트 단위가 팀 단위임을 인식합니다.
    예) ※ 이미지 업로드에 제한이 있는지 모릅니다!다음 달에 갱신합니다.
    컨텍스트 맵: 컨텍스트 간의 관계를 나타내는 그림입니다.사전에 이것을 잘 함으로써 팀 간에 어떻게 협력해야 하는지에 대한 계획을 더욱 쉽게 세울 수 있다.
    예) ※ 다음 달에 드리겠습니다!

    5. 각 상하문의 구조를 고려한다


    지금 추천하는 것은 육각형 건물입니다.
    예) ※ 다음 달에 드리겠습니다!

    6. 역, 상하문도, 구조를 바탕으로 원본 코드에 들어간다.


    예제)
    핵심 상하문(원격 관리 영역)의 프로젝트 구조.
    remainderManager
    ├── application
    │   ├── api #Restで外部とデータの受け渡しができる。UIとのデータのやりとりに使う。
    │   ├── dpo  #複数の集約データを取得して、詰め替えた値を持つ入れ物
    │   ├── dto  #複数の集約インスタンスの参照をプロパティにて持つ入れ物 
    │   └── service #domain層のセパレートインターフェイスを介して、集約を取得し、dtoやdpoに変換したりするロジック。
    ├── domain
    │   ├── factory #集約のルートとして実装。他のコンテキスト間とのやりとりを担う。
    │   ├── aggregation #集約。オブジェクト(entityや値オブジェクト)のまとまりを表す。
    │   ├── entity #一意なものを表現する概念。オブジェクト。ストーリーで書いたときの「変更」や「登録」等の動詞の主語に当たる部分が該当
    │   └── service #ドメインオブジェクトの外に記述した方が良いロジックの部分。infrastracture層のセパレートインターフェイスを介して、データを取り出して加工したりする。
    └── infrastructure
        ├── model #DBのデータを受け渡しするための入れ物。
        └── repository #DBからデータを追加、取得、更新、削除する。
    
    ※ 분리 인터페이스: 설치 클래스와 다른 층에 인터페이스를 발표함으로써 의존 관계를 간소화할 수 있습니다.

    7. 모듈의 구성


    하나의 필드에 모듈을 만듭니다.
    각 핵심 컨텍스트와 하위 컨텍스트는 모듈에 하위 모듈로 포함됩니다.
    예제)
    # モジュール名
    remainder
    # 認証・アクセスコンテキスト
    remainder.identityAccess.application
    remainder.identityAccess.domain
    remainder.identityAccess.infrastructure
    # リマインダー通知コンテキスト
    remainder.notification.application
    remainder.notification.domain
    remainder.notification.infrastructure
    # リマインダー管理コンテキスト
    remainder.notification.application
    remainder.notification.domain
    remainder.notification.infrastructure
    

    끝맺다


    도메인 구동 설계
    업무별로 분리돼 있기 때문에 각자 연락이 소외돼 보수적일 때는 서로의 반에 큰 영향을 주지 않아 편리하다고 생각한다.추가 기능 설치할 때도 편할 것 같아요.
    하지만 하나둘씩 DB 접근에서 인수인계까지 논리적으로 분리되기 때문에 설치하는 게 힘들 것 같은데...
    어딘가 보도에서 원가적으로...나도 위에 쓰여 있는 것을 알았다.
    나는 원가 방면을 중시하느냐, 아니면 복잡하기 쉬운 큰 프로젝트의 유지 보수를 중시하느냐 하는 것이 매우 고민이다.

    인용하다


    책에서 이해하다
    https://codezine.jp/article/corner/655
    경계 상하문 개념편
    https://little-hands.hatenablog.com/entry/2017/11/28/bouded-context-concept
    DDD의 도메인, 하위 도메인, 공통 언어, 경계 컨텍스트 정리https://qiita.com/crossroad0201/items/875c5f76ed3794ed56c4
    도메인 제어 설계가 해결할 사항 [DDD]
    https://qiita.com/little_hand_s/items/721afcbc555444663247

    좋은 웹페이지 즐겨찾기