헥사고날 아키텍처 걍 읽어만 봤는데 저런 소프트웨어 아키텍처 설명론은 솔직히 별로 안 와닿고 뜬구름 잡는 소리 같음그냥 평범하게 controller service repository 이렇게 layered 로 구성하는거랑 유지보수 측면에서 더 좋은 점이 있음? - dc official App
DDD는 쓰는데 헥사고날은 못봄 역사적 지식으로만 알고있으셈 - dc App
어짜피 핵심은 도메인 로직이 다른것에 의존성을 가지지 않게 하는거잖아 그런 측면에서 보면 다 비슷하지 뭐 - dc App
프레임워크가 도메인 영역을 침투를 안함. 그래서 테스팅에 유리함. 테스팅을 잘 짜면 도메인 언어가 잘 정립됨. 이론만 두고보면 안쓸 이유가 없음. 문제는 팀에 이걸 제대로 이해하는 사람이 얼마냐 있느냐지
이론상 최강 같은 느낌인데 제대로 이해하기 어려울 거 같음 ㅇㅇ. 지금까지 본 코드베이스들은 전부 그냥 layered architecture인데 크게 불편한 점은 못 느끼겠는데 말이지
예아
불편하지 않으면 그냥 쓰면 됨 레이어드도 좋은 아키텍처임
헥사고날로 짜여진 서비스 하나 유지하다가 딴팀한테 넘겼는데 헥사고날은 걍 이름만 거창한 아키텍쳐임 (그게 나쁘다는게 아니라). 그냥 프로그램 제대로 짜면 헥사고날이랑 비슷하게됨. 이름만 layer나 port이런게 아니다 뿐이지.
ㅇㅇ 이거맞음 결국에는 유닛테스트 가능한 프로젝트를 만들어가다보면 그 결과값이 결국 인터페이스를 가진 거닌까
이거 좃소에서 쓰다가 이해하는 사람이 없어서 포기함
뭐야 그냥 경계선 제대로 긋고 일하라는 말 아님? - dc App
DDD는 씀