Clean Architecture 정리 - 5부 30 - 32 000은 세부사항이다.

데이터베이스는 세부사항이다.

• 데이터베이스는 소프트웨어 시스템의 아키텍처적 관점에서 하위 세부사항에 불과함.
• 아키텍처에서 중요한 것은 단순한 데이터 구조나 접근 방식이 아니라, 도메인 개념을 반영한 데이터 모델링이다.

 

웹은 세부사항이다.

• 웹은 입출력 장치와 밀접한 관계를 가지며, GUI로 분류됨.
• 업무 규칙이 UI와 뒤섞이면, 마케팅 변화나 플랫폼 전환 시 전체 시스템에서 재활용할 부분이 적어진다.
• 아키텍처는 GUI와 같은 요소에서 업무 로직을 분리해 설계해야 함.
  • 유스케이스는 입력, 처리, 출력으로 구성된 업무 흐름이며, 이 흐름은 화면 구성과 무관하게 독립적으로 정의될 수 있음.
  • 이를 먼저 구조화해두면, 웹이든 데스크탑 앱이든 어떤 UI든 해당 흐름을 재사용할 수 있음.

 

프레임워크는 세부사항이다.

• 프레임워크의 업데이트로 기능이 삭제되거나 변경될 수 있어, 기존 코드에 영향을 줄 수 있음.
• 더 좋은 프레임워크가 등장하면 바꾸고 싶어질 수 있음.
• 프레임워크가 업무 객체(유스케이스 컨트롤러, 엔티티)를 만들 때 프레임워크 기반 클래스로부터 파생을 요구한다면, 이후에 프레임워크와 업무 규칙을 분리하기 어려워짐.
  • 대신 proxy(중간 계층)를 만들고, 업무 규칙에 플러그인할 수 있는 컴포넌트에 이들 proxy를 위치시켜야 함.

아래는 프레임워크 종속을 방지하는 React 예시 코드임:

// 유스케이스 인터페이스 (업무 규칙 계층)
interface ICreateUser {
  execute(input: { name: string; email: string }): Promise<void>;
}

// 프레임워크와 유스케이스 사이의 proxy 컴포넌트
function CreateUserForm({ useCase }: { useCase: ICreateUser }) {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    try {
      await useCase.execute({ name, email });
      alert('User created');
    } catch (err) {
      alert('Error');
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input value={name} onChange={(e) => setName(e.target.value)} placeholder="Name" />
      <input value={email} onChange={(e) => setEmail(e.target.value)} placeholder="Email" />
      <button type="submit">Create User</button>
    </form>
  );
}

// 사용하는 곳에서 의존성 주입
<CreateUserForm useCase={createUserUseCase} />

• 이 구조에서는 React 컴포넌트가 프레임워크에 종속된 UI만 담당하고,
• 실제 업무 로직인 useCase는 외부에서 주입되어 테스트나 교체가 쉬움.
• React가 아닌 다른 UI 프레임워크로도 같은 useCase를 재사용 가능함.
  
  

※ 본 글은 『Clean Architecture』(로버트 C. 마틴 저) 5부 30 - 32장을 기반으로 학습 목적으로 요약한 글입니다.

※ 이 글은 책의 내용을 요약한 것으로, 원문 없이 읽을 경우 오해의 여지가 있을 수 있습니다. 정확한 이해를 위해 원서의 정독을 권장합니다.