가장 중요하고 , 잘 변하지 않는 것부터 시작하기
핵심 사용자 시나리오 정하기
가변요소
ex)회원정보를 어떻게 저장할 것인지 , 회원가입 괒어이 몇 페이지에 걸쳐서 이루워 질지.. 이런 것처럼 코드 작성 시 변할 수 있는 것들
비교적 불변요소
ex)회원에게 어떤 정보를 꼭 받아야 하는지 , 회원과 비회원의 차이는 무엇인지.. 문과적인 감성이 들어간 코드 작성시 상대적으로 변경 될 가능성이 적은 것들
핵심 사용자 시나리오 코드화하기
-해김 사용자 시나리오를 구현하기 위한 코드 작성하기
Domain Layer
-Data Layer와 UI Layer 이 사이에 무엇인가를 만들 때 알고 있어야 할 것들
Domain Layer 정의
-UI 계층에서 사용되기 위해서 캡슐화된 비즈니스 로직들을 모아 놓은 곳
- 캡슐화가 굉장히 중요하기 때문에 도메인 계층 내부에서 비즈니스 로직들도 이런 게 이런 게 필요하고 어떤 일을 한다라는 것이 인터페이스 형태로만 존재하고 , 그 안에서 실제로 어떠한 것이 이루어지는지는 감쳐줘있다. 이렇게 함으로서 도메인 비즈니스 로직의 복잡성을 감출 수 있다.
-Domain 계층의 비즈니스 로직은 UI 계층의 비즈니스 로직과는 다르다.
-
Domain 계층의 비즈니스 로직은 진짜 비즈니스 로직 , 앱의 기획자 같은 사업 부서 사람들이 알아야 될 것같은 로직들이 들어있어
-
UI와 Dependency가 없는 그런 비즈니스 로직들이 들어가는 곳이 Domain 계층의 비즈니스 로직이다.
-
UI 계층의 비즈니스 로직은 사용자의 입력에 따라서 서버로 보내거나 DB에 저장하는 것 같이 UI와 관련된 로직들을 의미한다. 즉, 사용자 인터페이스와 관련된 결정들을 포함하는 것을 비즈니스 로직이라고 한다.
Domain Layer로 나누어서 코드를 넣는 이유
UI 계층과 Data 계층 사이에 있는 책임들을 분리해준다.
-UI 계층이 바라보는 액터와 Data 계층이 바라보는 액터가 다른데 그 중간 사이에서 어떤 가교 역할을 해줄 수 있는 역할을 하기 위해서.
비즈니스 규칙/전략의 변경이 타 계층에 영향을 주지 않는다.
-완전히 100% 안미치기는 어렵겠지만 최대한 독립성을 추구해야 한다.
코드 중복을 합리적으로 줄여줌
-비즈니스 로직이 여기저기 분산되는 것을 막기 위해서 중복을 막아 줄 수 있다.
테스트 용이 : 비즈니스 로직만 테트스 할 수 있음
Domain Layer에서 하는 일
Domain 비즈니스 로직
-UI 계층과 Data 계층의 비즈니스 로직들과는 별개로 독립된 독립적인 비즈니스 로직을 코드화한다.
데이터의 변환
-Data 계층에서 전달 받은 엔티티(DB 테이블 , API를 통해서 받은 JSON등이 그대로 매칭되는 것들을 의미한다)를 앱의 도메인 관점에서 사용 할 수 있게 변환해준다.
-서버관점 : 서버에서 받아온 경우라면 서버의 관점에서의 어떤 필드 또는 스키마를 갖고 있을것이야.
-도메인관점 : 앱에서만 의미있는 데이터 형태로 바꾸는 것
UI 계층에서 중복 사용되는 공통 로직 가져오기
-UI 계층에서 중복 사용되는 공통 로직을 무조건 Domain 계층으로 옮길 수 있는 것은 아니지만 , UI 계층에서 사업에 관련된 비즈니스 로직이 있다면 Domain 계층으로 옮길 수 있다.
-따라서 코드의 중복을 낮게 만들 수 있다.
Domain Layer를 잘 설계하는 것이 중요한 이유
UI 계층과 Data 계층 사이의 중간이 없을 때 생기는 설계상의 문제 해결
-UI 계층과 Data 계층 사이의 중간이 없을 때 생기는 설계상의 문제들을 해결 할 수 있다.
-예를들어 UI Layer에서 만들어진 ViewModel이 너무 강하게 결합되어 있다면 DomainLayer로 옮김으로서 결합을 끊을 수 있게 된다.
UI의 편안함
-전체적인 로직이 너무 UI에 집중하게 되면 화면중심의 코드가 되어서 수정이 힘들다.
좋은 Domain Layer
-데이터/엔티티 중심의 사고방식으로는 좋은 설계를 만들 수 없다. 오히려 핵심 행위와 액터를 추상적인 형태로 만드는 사고방식을 통해서 Domain Layer를 구성하는 것이 더 아름다운 Domain Layer를 만들 수 있게 해준다.
디디디!
-디디디!!란 Domain Layer를 개발의 주축에 두고 개발하는 도메인 주도 설계 이론을 의미한다.
-UI 계층과 Data 계층 사이를 어떻게 연결할 것인가에 대한 것을 접할 정보가 거의 없었는데 이제 초반단계니까 기술적으로 이끌어 나갈 수 있을 수도
-화면중심의 사고로 다루는 것보다 훨씬 안정적인 설계를 할 수 있다.
-DDD는 불변하는 Domain Layer를 어떻게 올바르고 효과적으로 설계하는 지에 대한 정보를 알려준다.
