앱에서 DDD를 적용하는 것이 맞는걸까요?

Question

앱에서 DDD를 적용해보려고하는데 어려움이 있어 질문드립니다. 앱단에서 어플리케이션 레이어의 서비스는 어떻게든 식별해서 진행이되는데 어그리게잇, 엔티티, 값 객체에서 막막하게 느껴집니다. 막막하게 느껴지는 이유는 결국 데이터를 최종적으로 받아서 저장하는 로직들은 서버단에서 처리를 할 텐데요. 이런 경우에 결국 앱에서는 임시로 데이터를 들고 있는 자료구조 혹은 vo라고 느껴지고 있습니다. 아니면 앱이라는 환경속에서 어그리게잇, 엔티티, 값 객체를 뽑는 것도 생각을 했는데 아직 머리속으로 구조가 잡히지 않고 어떤 방향으로 가는게 좋은지 확신이 들지 않는데요. 어떻게 나아가야할지 좋은 의견 부탁드립니다.

han jeong heon · Answer

네 안녕하세요. 제가 프론트나 앱 개발을 한경험이 많지 않아서 조심스럽게 의견을 드립니다. DDD가 도메인 중심으로 사고하고 그 개념을 어플리케이션에 알기 쉽게 표현한다는 점에서 프론트나 앱에 적용 못할 이유는 없을 것 같습니다. 아래와 같이 실제 사례들도 많이 발표되고 있고요. 프론트(앱)가 의미있는 비지니스를 가지고 있고 그것이 도메인모델로 잘 표현될 수 있다면 못 할 것도 없습니다. https://betterprogramming.pub/domain-driven-architecture-in-the-frontend-i-d27fb71b5cb0 https://khalilstemmler.com/articles/typescript-domain-driven-design/ddd-frontend/ 다만 언급하신 바와 같이 아키텍처가 프론트와 백엔드로 구분되어 있고 대부분의 비지니스 로직이 백엔드에 존재해야 한다면 굳이 프론트 영역의 구조를 그렇게 가져갈 필요는 없다고 생각합니다. 말씀을 통해 유추해 보면 프론트에 어플리케이션 레이어는 필요하다고 가정하고. 대부분의 비지니스 로직은 백엔드에 있다 하면 ... 프론트(앱)은 앱에 필요한 레이어 + 어플리케이션 레이어 백엔드는 프리젠테이션 레이어 -> 비지니스로직 레이어(도메인 모델:어그리거트+엔티티+vo등) -> 데이터 액세스 레이어 의 구조로 정의해도 괜찮을 것 같습니다. 감사합니다.