클린 코더스 강의 요약(Architecture) - 5

What is Architecture?

* 전체적인 시스템 개발에 기반을 제공하는 변경 불가능한 초기 결정사항의 집합

Java, Spring, MySQL, MVC 같은 것이 아닌, 사용법(설계)에 대한 것

 

What is UseCase ?

* 일련의 단계의 집합

* Actor(목적이 같은 클라이언트 집단) 와 시스템의 상호작용을 정의해둔 것들

* Architecture exposes usage

 (MVVM 을 사용했고, Repository 패턴을 적용했고, 디비는 Room 을 적용했고 같은 것들로 일부가 표현될 수는 있지만 정확하게는 아님 - 전자는 Application 이 어떤 목적으로 만들어졌고 어떤 기능을 하는지에 대해 알려주지 못한다)

클린 코더스 강의에서는 위의 사진 같은 것이 좀더 아키텍쳐에 가깝다고 표현하고 있다.

ATM 프로세서는 카드 리더와, 예금 슬롯을 가지고 있고,  패널을 가지는데 패널 모듈은 디스플레이와 키보드 모듈을 가지고 있다.

이런 목적과 기능에 대한 명세가 필요하지, MySQL 을 사용하고 Retrofit 을 사용하고 이런 것들(Delivering 메커니즘)을 표기하는 것은 아키텍쳐 본연의 의미를 담지 못한다.

 

Deferring Decisions(결정들 미루기)

좋은 아키텍처는 프레임워크, WAS, UI, Library 등과 같은 것들에 대한 결정을 연기하는 것을 허용해야한다(시간이 지날수록 결정을 위한 정보가 풍부해진다)

(개발자가 모든 것에 대해 알 수 없고, 이후 정보를 얻으면서 시스템에 변경이 필요할 수 있고 좋은 아키텍쳐는 이런 변경을 유연하게 만든다 - 내가 모르는 것이 무엇인지 모른다..!)

 

도메인 모델 개발 순서

1. 어떤 클래스가 존재하는지 찾고, 그 클래스들이 어떤 속성을 가지고 있는지 찾고, 각 클래스들의 관계를 식별한다.

2. 요구 사항을 정리하고, 메서드들로 나눠내고(extract interface), 실제로 메서드를 구현(implementation)한다.

 

UseCases

* 사용자가 특정 목적을 이루기 위해 시스템과 어떻게 상호작용하는지에 대한 형식적 기술

* 시스템에 들어가는 데이터, 커맨드와 시스템이 응답하는 것만 언급

* Delivery 메커니즘과 무관한 아키텍처를 가지려면 Delivery 매커니즘과 무관한 use case 로 시작해야 한다.

* 입력 데이터를 해석하여 출력 데이터를 생성하는 필수 알고리즘

* 비즈니스 규칙을 내포하고 있음

 

Business Object : Entity 

UI Object : VO, DTO

Use case Object : Interactor 라고 보통 표현함

 

Entity 가 가져야하는 것

- Application 과 독립적인 비즈니스 로직

- 다른 Application 에서도 Entity 는 사용되고 같음

- 특정 Application 에 특화된(의존성) 메서드를 가지만 안됨 (이런 경우는 Interactor 로 옴길 필요가 있음)

 

Interactor 가 가져야하는 것

 - Application 종속적인 비즈니스 로직

 - 특정 Application 에 특화된 메서드들은 Interactor 객체에 구현

 - Interactor 는 Application 에 특화된 로직을 통해 목적을 달성