4장 도메인의 격리

[y2o2u2n]

계층형 아키텍처

도메인에 관련된 코드가 도메인과 관련이 없는 코드에 퍼져 있는 경우 도메인에 관련된 코드를 확인하고 추론하기 어려워진다. 이렇게 되면 프로그램을 이해하기가 어려워진다.

• 사용자 인터페이스
• 응용
• 도메인
• 인프라스트럭처

계층형 아키텍처 중 일반적인 형태는 위와 같은데, 주 목적은 도메인 계층을 분리하는 데 있다. 그리고 상위 계층에서 하위 계층으로 의존성을 한 방향으로만 둬서 느슨하게 결합해야 한다.

[chanhyeong]

LAYERING 의 가치

각 계층에서 프로그램의 특정 측면만을 다룬다 토대로 응집력 있는 설계 -> 설계를 쉽게 이해

name	description
User Interface	사용자에 view + 사용자의 command 외부 컴퓨터가 될 수도 있음
Application	소프트웨어가 수행할 작업 정의 + 도메인 객체가 문제를 해결 다른 시스템의 application layer 와 상호작용 얇게 유지 (업뮤 규칙 및 지식이 없음, 작업을 조정하고 도메인 객체의 협력자에 작업 위임) 업무 상황의 상태는 없지만 프로그램 작업의 진행 상태는 가질 수 있음
Domain	업무 개념 + 상황 + 규칙을 표현 업무 상태 제어 및 사용, 상태 저장과 기술적인 세부 사항은 infra 에 위임 업무용 소프트웨어의 핵심
Infrastructure	기술적인 기능 메시지 전송, persistence, ui rendering

upper -> lower layer 호출 시

• public interface or generally using conventional means of interaction
• 굳이 public interface 를 만들지 않더라도 conventional means 가 있다면 직접 호출해도 된다는 의미 아닌지?
  • 개인적으론 interface - Impl 의 형태를 싫어해서
• 구현을 강제할거면 ArchUnit 을 도입하는게 나을 듯

lower -> upper

callback 이나 Observer 패턴 (패턴 공부의 필요성..)

Architecture Framework

• framework 를 적용할 때는 framework 의 목적을 봐야 함
  • 도메인 모델을 표현하고 구현하는 것
• 모든 기능을 사용하는게 아님
• 하나로 전부 해결하기보단 여러 framework 선택

[bearics]

p73 credit($100), debit() 도메인 단위에서 진행하는데 어떻게 코딩하면 좋을까요

class Account {
    long amount;

    public void debit(long amount, Account another) {
        this.amount += amount;
        another.minus(amount);   << 자신외의 인스턴스를 업데이트해도 괜찮을까
    }

}

// 서비스 단에서 하는게 더 직관적이지 않을지... 응용 service? 도메인 service? 110p
class AService {  
    public debit(Account A, Account B, long amount) {
        B.minus(amount);
        A.plus(amount);
    }
}