clean architecture / hexagonal architecture 도 다 포함되는 그런 이야기랄까
many to many 로 만들어야하는 구조이고
결국 하나는 aggregate root 이 되어야하는데
여기서 어떤게 장기적으로 봣을때 aggregate root 이 되어야 적절할지를 판단내리는것도 어렵다
좋은 code level architecture 를 잡고가는지도 잘모르겟고
고민의 고민의 고민
댓글 5
aggregation도 하나의 역할이라 생각하면 그것만 담당하는 역할을 또 따로 생각하게 되던데
익명(45.14)2023-06-12 16:27
이렇게 한 2~3년차되서 디자인패턴 같은거 배워놓으면 온갖 곳에 디자인 패턴을 집어넣을려고 용을 씀. 그러다가 몇개월 후에 다른 프로젝트하다가 다시 유지보수하러 오면 왜 이렇게 어렵게 짠거지? 하고 생각되는 경우가 종종 있어. 결국 읽기 쉬운 단순한 코드가 나을 때가 많음. 여길 이렇게 해서 확장 가능성을 열어두는게 나은.. 이라고 하지만 실제로 확장을 써보기도 전에 레거시시스템으로 묻히는 경우가 태반.
aggregation도 하나의 역할이라 생각하면 그것만 담당하는 역할을 또 따로 생각하게 되던데
이렇게 한 2~3년차되서 디자인패턴 같은거 배워놓으면 온갖 곳에 디자인 패턴을 집어넣을려고 용을 씀. 그러다가 몇개월 후에 다른 프로젝트하다가 다시 유지보수하러 오면 왜 이렇게 어렵게 짠거지? 하고 생각되는 경우가 종종 있어. 결국 읽기 쉬운 단순한 코드가 나을 때가 많음. 여길 이렇게 해서 확장 가능성을 열어두는게 나은.. 이라고 하지만 실제로 확장을 써보기도 전에 레거시시스템으로 묻히는 경우가 태반.
ㅇㄱㄹㅇ
이건좀팩폭이네요
무슨 패턴 쓰건 간에 유지보수 쉬우면 장땡임