결국 설계의 방향성은 프레임워크에서 어떻게 훅을 걸어서 하느냐가 중요한거라..

프레임워크 여러개 써서 그 안에서 도메인의 순결함을 지키기 위해 만들어진 헥사고날을 쓰건, 클린 아키텍트를 쓰건

레이어드를 쓰건 그거야 별로 중요하지 않고

결국 중요한건 내가 '어디까지' 인지를 하느냐라는 인지 구분이 중요함

당장 클린 아키텍쳐가 단방향 의존성을 가지기때문에 단방향 의존성에서 

UI->유스케이스->도메인->엔터티 이렇게 한다해도 이걸 관통할 DTO 생성 잘못하면 말짱 황이고

결국 핵심은 어떤 아키텍쳐를 '반드시' 지키는게 아니라

프레임워크의 확장 지점을 이해하고, 비즈니스 로직(도메인)의 순결성을 어떻게 보장하느냐. 라는게 정확한 이해임

처음에는 형태를 따르게 되있지만 결국 기능이 중요한거지. 그 기능

즉 도메인의 순결성을 어떻게 보장하고, 이 도메인의 순결성 보장은 프레임워크마다 다르기때문에 그 경계 설정이 중요한거라

어떤 프레임워크가 전제되지 않는 상황에서 아키텍쳐를 설계한다는 건 그건 그냥 집 지을 재료가 없는 추상적으로 생각만한다랑 다를바가 없음

물론 도메인 경계(ports)와 정책은 프레임 워크 없이도 고정할 수 있지만, 이건 프레임워크에 따라서 엄연히 바뀔 수 있는 영역이라서 결국 어떤걸 선택하느냐가 먼저되야함

프레임워크를 쓴다는 건 건축으로 따지면 재료고, 아키텍쳐는 그 재료의 하중등을 고려해서 어떤 모양으로 만들지니까