Portfolio

애플리케이션 구분하기

업무규칙

플러그인

업무규칙

사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차

핵심 업무 데이터

핵심 업무 규칙은 보통 데이터를 요구한다.

엔티티

핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있음 → 객체로 만들 좋은 후보

이러한 유형의 객체를 Entity라고 함

(엔티티를 만드는 데 꼭 객체 지향 언어를 사용할 필요는 없다)

핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙 구체화

엔티티 객체는 핵심 업무 데이터를 직접 포함하거나 핵심 업무 데이터에 매우 쉽게 접근할 수 있음

EX) 대출 (Loan) 객체

세가지 핵심 업무 데이터 포함

데이터와 관련된 세 가지 핵심 업무 규칙을 인터페이스로 제공

유일한 요구조건은 핵심 업무데이터와 핵심 업무 규칙을 하나로 묶어서 별도의 소프트웨어 모듈로 만들어야 한다

유스케이스

엔티티 내부의 핵심 업무 규칙을 어떻게, 그리고 언제 호출할지를 명시하는 규칙을 담는다.

엔티티가 어떻게 춤을 출지를 유스케이스가 제어하는 것

유스케이스는 시스템이 사용자에게 어떻게 보이는지를 설명하지 않는다.

애플리케이션에 특화된 규칙을 설명하며, 이를 통해 사용자와 엔티티 사이의 상호작용을 규정한다.

시스템에서 데이터가 들어오고 나가는 방식은 유스케이스와는 무관하다.

유스케이스는 객체다

유스케이스는 애플리케이션에 특화된 업무 규칙을 구현하는 하나 이상의 함수를 제공한다.

엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못한다.

엔티티와 같은 고수준 개념은 유스케이스와 같은 저수준 개념에 대해 아무것도 알지 못한다.

반대로 저수준인 유스케이스는 고수준인 엔티티에 대해 알고 있다.

Q. 왜 엔티티는 고수준이며 유스케이스는 저수준일까?

A. 왜냐면 유스케이스는 단일 애플리케이션에 특화되어 있으며, 따라서 해당 시스템의 입력과 출력에 가깝게 위치하기 때문이다. 엔티티는 수많은 다양한 애플리케이션에서 사용될 수 있도록 일반화된 것이므로, 각 시스템의 입력이나 출력에서 더 멀리 떨어져 있다.

유스케이스는 엔티티에 의존한다. 반면 엔티티는 유스케이스에 의존하지 않는다.

요청 및 응답 모델

유스케이스는 입력 데이터를 받아서 출력 데이터를 생성한다.

그 어떤 사용자 인터페이스에도 종속되는것이 없어야 한다.

의존성을 제거하는 일은 매우 중요하다.

엔티티와 요청/응답 모델은 상당히 많은 데이터를 공유하므로 이러한 방식이 적합해 보일 수도 있다.

but nono 이들 두 객체의 목적은 완전히 다르다.

시간이 지나면 두 객체는 완전 다른 이유로 변경될 거고,

이 두 객체를 어떤식으로든 함께 묶는 행위는 공통 폐쇄 원칙과 단일 책임 원칙을 위배하게 된다.

결국 코드에는 수많은 떠돌이 데이터가 만들어지고 수많은 조건문이 추가된다.

결론 : 업무 규칙 이란

소프트웨어 시스템이 존재하는 이유

핵심적인 기능

수익을 내고 비용을 줄이는 코드를 수반한다

집안의 가보다

사용자 인터페이스나 데이터베이스와 같은 저수준의 관심사로 인해 오염되어서는 안 되며, 원래 그대로의 모습으로 남아있어야 한다.

이상적으로, 업무 규칙을 표현하는 코드는 반드시 시스템의 심장부에 위치해야 하며, 덜 중요한 코드는 이 심장부에 플러그인되어야 한다.

시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 한다.

20 업무 규칙