DTO VO Entity 분리이유

질문 하신 3가지 이외에 Domain 까지 함께 얘기해 볼 수 있을 것 같습니다. 먼저 간단히 4가지에 대한 의미를 되짚어 보면 좋을 것 같습니다. - DTO는 프리젠테이션 레이어(예: React 프런트엔드)와 비즈니스 로직 레이어(예: 백엔드) 사이와 같이 애플리케이션 레이어 간에 데이터를 전송하는 데 사용됩니다. 일반적으로 전송해야 하는 데이터는 포함하지만 동작이나 비즈니스 로직은 포함하지 않습니다. - VO는 DTO와 유사하지만 일반적으로 애플리케이션 내에서 변경할 수 없는 값을 나타내는 데 사용됩니다. DTO와 마찬가지로 VO에는 동작이나 비즈니스 논리가 포함되어 있지 않습니다. 예를 들어 VO를 사용하여 금전적 금액, 날짜 또는 위치를 나타낼 수 있습니다. Adress 라는 VO 를 만들어 관리한다면 지역구 정보 시, 구, 동을 묶어서 하나의 주소라는 단위로 관리할 수 있으며, 변경 할 수 없는 특성으로 동 만 변경하려면 새로운 Adress 새로 만들어 써야 합니다. - 대부분의 애플리케이션에서 Entity는 데이터베이스 테이블의 행을 나타내는 클래스입니다. Entity 의 속성은 데이터베이스 테이블의 열에 해당하며 엔터티의 각 인스턴스는 테이블의 단일 행을 나타냅니다. - 도메인 객체는 애플리케이션의 핵심 비즈니스 로직을 나타내며 일반적으로 엔티티의 동작을 구현하는 데 사용됩니다. 복잡한 비즈니스 로직을 캡슐화하고 비즈니스 규칙을 검증하며 계산을 수행하는 데 자주 사용됩니다. 도메인을 따로 분리하여 관리 하지 않는 경우 Entity 에도 동일한 역할을 수행하기도 합니다. 일반적으로 DTO <-> Domain <-> Entity 와 같이 분리를 하는 것이 좋습니다. 이렇게 분리를 하게 되면 추후 변경 사항에 대해서 유연하게 대응할 수 있어 코드의 유지 관리에 유리합니다. 예를 들어 DTO <-> Domain 관계에서 기존에 API는 이름을 통째로 받다가 변경이 되어 성과 이름을 분리하기로 했다면 DTO만 수정하여 대응하면 됩니다. 만약 분리되어 있지 않았다면 더 복잡한 과정을 거쳐 수정이 이뤄져야 할 것입니다. Domain <-> Entity 가 분리되어 있다면 DB 테이블 스펙이 변경되어 코드에 반영이 필요한 경우에도 Entity 변경만을 통해 기존 Domain에 영향을 주지 않을 수도 있습니다. 그 밖에도 확장성에도 유용한데, Domain 은 그대로 유지한 채 요구사항에 맞춰 추가되는 API 들은 여러 유형의 DTO 로 확장할 수도 있습니다. DTO, Entity 및 Doamin 개체를 분리하는 것은 필수는 아니지만 코드의 구조와 유지 관리성을 개선하는 데 도움이 될 수 있으며 일반적으로 소프트웨어 개발에서 좋은 사례로 간주됩니다.