핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가 된다.
이러한 유형의 객체를 엔티티(Entity)라고 부른다.
📕 엔티티
- 컴퓨터 시스템 내부의 객체
- 핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체화
- 업무 데이터를 직접 포함하거나 핵심 업무 데이터에 쉽게 접근 가능
엔티티 생성 시에는, 핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어서 별도의 소프트웨어 모듈로 만든다.
📗 유스케이스
- 자동화된 시스템이 사용되는 방법을 설명
- 수동 환경에서는 사용 불가
- 유스케이스는 사용자가 제공해야 하는 입력, 사용자에게 보여줄 출력, 그리고 해당 출력을 생성하기 위한 처리 단계를 기술
- 애플리케이션에 특화된(application-specific) 업무 규칙을 설명
- 엔티티 내부의 핵심 업무 규칙을 어떻게, 그리고 언제 호출 할지 명시하는 규칙을 담는다.
- 사용자 인터페이스를 기술하지 않는다.
- 시스템이 사용자에게 어떻게 보이는지 설명하지 않는다.
- 유스케이스는 객체다.
- 애플리케이션에 특화된 업무 규칙을 구현하는 하나 이상의 함수를 제공한다.
왜 엔티티는 고수준이고 유스케이스는 저수준일까?
- 유스케이스는 단일 애플리케이션에 특화되어 있어, 해당 시스템의 입력과 출력에 가깝게 위치하기 때문
- 엔티티는 수많은 다양한 애플리케이션에서 사용될 수 있도록 일반화된 것이므로, 각 시스템의 입력이나 출력에서 더 멀리 떨어져 있음
유스케이스는 엔티티에 의존하지만 엔티티는 유스케이스에 의존하지 않음
📙 요청 및 응답 모델
유스케이스는 입력 데이터를 받아서 출력 데이터를 생성한다.
- 유스케이스 클래스의 코드가 HTML이나 SQL에 대해 알게하면 안된다.
- 의존성을 제거하는 것은 매우 중요하다.
- 요청 및 응답 모델이 독립적이어야 한다.
- 두 객체의 목적이 완전히 다르기 때문에 추후 다른 이유로 변경될 수 있기 때문이다.
- 위반할 경우 공통 폐쇄 원칙과 단일 책임 원칙을 위배
📘 결론
- 업무 규칙은 소프트웨어 시스템이 존재하는 이유다.
- 업무 규칙은 UI나 데이터베이스 같은 저수준의 관심사로 인해 오염되어서는 안되며, 원래 그대로 모습을 유지해야 한다.
- 업무 규칙을 표현하는 코드는 반드시 시스템의 심장부에 위치해야 하며, 덜 중요한 코드는 이 심장부에 플러그인 되어야 한다.
- 업무 규칙은 시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 한다.
📚 Reference
- Clean Architecture : 소프트웨어 구조와 설계의 원칙
로그를 생활화