Entity, DTO, VO 전부다 카지노 가입 쿠폰니까
Object-oriented programming (OOP) is a Programming paradigm based on the concept of Object
위 내용은 카지노 가입 쿠폰 지향 프로그래밍(OOP, Object-oriented programming)의 위키피디아 설명 첫 문장입니다. [1] 많은 다른 개발자들과 이야기를 나누다 보면 각자 생각하는 카지노 가입 쿠폰의 개념(concept of objects)이 굉장히 다양하다는 사실을 항상 느끼곤 합니다. 물론 미래의 제가 생각하는 카지노 가입 쿠폰의 개념은 다를 수도 있지만 현재의 제가 생각하는 카지노 가입 쿠폰의 개념에 대해서 글로 정리해보고자 합니다.
서버 개발을 진행하다 보면 특정 용어로 정의된 카지노 가입 쿠폰를 많이 만나게 됩니다. 그 여러 카지노 가입 쿠폰 중 가장 서버의 내부에 존재하는 카지노 가입 쿠폰는 바로 엔티티(Entity)입니다. 엔티티의 정의 역시 큰 틀은 다르지 않겠지만 사람마다 생각하는 정의가 아주 약간씩 다르곤 합니다. 제가 생각하는 정의와 가장 비슷하고 간결한 내용은 바로 Oracle docs에 남아있는 Java EE 6 Tutorial의 내용입니다
An entity is a lightweight persistence domain object. Typically, an entity represents a table in a relational database, and each entity instance corresponds to a row in that table. The primary programming artifact of an entity is the entity class, although entities can use helper classes.
위 글에서는 엔티티를 영속성이 있는 경량 도메인 카지노 가입 쿠폰라고 표현합니다. 영속성과 관련된 내용은 Java Tutorial 인 만큼 JPA(Java Persistence API)와 매우 큰 강결합을 가지고 있기에 여기서는 다루지 않겠습니다. [2]
그다음 이어지는 경량의 의미 역시 저는 다른 의미로 좋다고 생각합니다. 때때로 경량의 의미가 마치 빈약한(Anemic) 도메인 모델과 같은 형식처럼 들리기 때문입니다. 비록 제가 무척이나 좋아하는 마틴 파울러는 빈약한(Anemic) 도메인 모델을 카지노 가입 쿠폰 지향에 반하는 안티패턴으로 간주하고 있지만 저는 해당 의견이 쓰인 시점을 다시 생각해 볼 필요가 있다고 생각합니다.
마틴 파울러의 빈약한 도메인 모델과 관련된 글은 무려 20년 전에 쓰였는데, 당시에는 거대한 모노리틱 서비스들이 운영되던 시기였습니다. 단순한 함수 호출만으로도 여러 서비스의 경계를 넘나들 수 있었으며 의도치 않은 상태의 노출은 해당 상태를 깨지기 쉽게 만들 수 있었습니다. 하지만 MSA(Micro-Serivce Architecture) 환경에서는 조금 다릅니다. 사용자의 행동에 따른 비즈니스 로직을 구현하기 위해 여러 서비스들을 경유합니다. 잘 쪼개진 하나의 마이크로 서비스는 잘 응집된 도메인 카지노 가입 쿠폰처럼 느껴질 수 있다고 생각합니다. 그렇다면 컨트롤러나 서비스 레이어에서 도메인을 다루는 행위가 존재하는 것이 마이크로 서비스가 도메인 모델을 잘 나타내는 것처럼 느껴질 수 있습니다.
엔티티가 DB로부터 서비스로의 방향의 경로에 존재하는 카지노 가입 쿠폰라면, 외부 인터페이스로부터 서비스 방향에는 DTO(Data Transfer Object)가 존재합니다. 마틴 파울러는 DTO를 아래와 같이 정의합니다.
The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.
해당 정의에서 가장 눈에 띄는 지점은 serializable(직렬화 가능성)이라고 생각합니다. 바꾸어 말하자면 DTO는 직렬화/역직렬화 모듈과 강한 결합을 가지고 있다고 말할 수 있을 것 같습니다. 어떠한 응답이나 요청의 인터페이스는 바뀌지 않았지만 가끔 의도치 않은 직렬화 모듈의 설정으로 인해 DTO는 예민하게 반응할 수 있습니다. 또한 위의 정의에 따른다면 결국 한 서비스 내부의 레이어를 넘나드는 카지노 가입 쿠폰의 경우는 직렬화를 하지 않기 때문에 DTO라고 부르기는 조금 어색해 보입니다.
MSA 환경에서 다른 서비스로의 조회 요청에 대한 응답 DTO는 다른 서비스의 엔티티와 밀접히 연관되어 있는 경우가 많은 것 같습니다. 두 가지 카지노 가입 쿠폰가 전부다 애플리케이션 외부에서의 어딘가로부터 카지노 가입 쿠폰를 가져온다는 의미에서는 굉장히 유사하게 느껴지기도 합니다.
엔티티와 DTO는 외부로부터 내부로 향하는 방향이라면 내부끼리에서 만들어지는 카지노 가입 쿠폰는 VO 가 있다고 할 수 있을 것 같습니다. 역시나 마틴 파울러는 VO를 아래와 같이 정의했습니다.
When programming, I often find it’s useful to represent things as a compound. A 2D coordinate consists of an x value and y value. An amount of money consists of a number and a currency. A date range consists of start and end dates, which themselves can be compounds of year, month, and day.
여기서는 compound라는 용어가 참으로 좋게 느껴집니다. compound를 단어 그대로 해석하면 화합물이라고 읽히는데 이는 마치 여러 개의 카지노 가입 쿠폰가 잘 버무려져 있는 형태를 떠올리게 되는 것 같습니다. 오버 엔지니어링의 단점을 한 번 크게 느껴본 후에는 최대한 필요한 코드만을 작성하려고 노력하는 편입니다. 하지만 그럼에도 불구하고 중간 카지노 가입 쿠폰를 꼭 만들고 싶은 때가 있다면 바로 서로 다른 두 종류의 카지노 가입 쿠폰를 하나로 묶어서 처리하도록 강제하고 싶거나, 특정 값을 변환하거나 감추는 행동을 하고 싶은 경우에는 중간 카지노 가입 쿠폰를 만드는 것이 굉장히 유용합니다. 아니 어쩌면 만들지 않는 것이 잘못되게 느껴지고는 합니다.
그럼 다시 처음으로 돌아가보겠습니다. 변수명 하나에도 서로 의견이 다른 개발자들 사이에서 카지노 가입 쿠폰의 개념이 서로 다른 것은 크게 이상한 일이 아닙니다. 하지만 문득 왜 각자 생각하는 카지노 가입 쿠폰의 개념이 다른지에 대해서 깊게 고민해 본 적이 없다는 것을 알았습니다. 이 글을 쓰면서 정리된 제 생각은 결국 각자 생각하는 개발 원칙과 해당 원칙을 지키기 위해 해야 하는 수준이 다르다고 느끼기 때문이 아닐까 추측해 봅니다. [3] 누군가에게는 특정 카지노 가입 쿠폰에 행위가 꼭 있어야만 유지보수성이 높다고 생각할 수 도 있고 또 다른 누군가는 다르게 생각할 수도 있습니다. 결국 여기에 정리한 제 방식대로의 카지노 가입 쿠폰의 개념은 제가 지키고자 하는 개발 원칙에 따른 생각일지도 모릅니다.
약간 글의 큰 주제와 벗어났을지 모르지만 MSA 환경에 있기 때문에 한 서비스를 운영하기 위해 여러 서버를 띄우는 경우도 있습니다. 덕분에 여러 관점들을 각기 다른 서버에 적용해 보고 운영해 나가며 비교할 수 있는 장점 또한 가져갈 수 있게 된 것 같습니다. 이 글을 쓰는 지금은 아쉽게도 그 장점을 누리기 어려운 환경에 있지만 언젠가 또 다른 새로운 생각을 가진 개발자 분이 오게 되면 기쁜 마음으로 그분의 생각이 담긴 코드를 보며 즐겁게 이야기할 날이 오기를 기대해 보곤 합니다.
[1] 능력과 직장과 같은 현실적인 문제를 조금이나마 해소할 수 있다면 함수형 패러다임을 사용하는 곳에서 일해보고 싶은 생각도 종종 하곤 합니다.
[2] 가볍게 현재의 생각을 공유하자면, JPA에서 제공하는 영속성 콘텍스트와 관련된 부분의 기능을 잘 사용하지 않으려고 합니다. 큰 이유로는 사용하고 있는 코틀린 환경이 JPA와 잘 맞지 않는 부분과 더불어 영속성 콘텍스트의 내부 이해도를 높이기 어려운 점과 작동 방식이 암시적이라는 점 때문입니다. JPA의 전체 기능을 잘 쓰지 못한다는 맹점에서 자유롭지는 못하지만 영속성을 제외하고도 JPA는 충분히 선택한 말한 선택지 임에는 틀림없습니다. 아, 여력이 된다면 Exposed는 꼭 사용해보고 싶긴 합니다.
[3] 제가 현시점 중요하게 생각하는 개발 원칙에 대해서도 글로 써 내려가볼 기회가 있었으면 좋겠습니다. 글을 쓰는 시점에는 또 다른 원칙이 생기거나 사라졌을지 모르니 여기에도 간략하게나마 적고자 합니다.
- 상황에 따른 성능과 리소스를 적절히 고려한다.
- 코드를 간결화하고, 중복을 최소화하며 코드의 재사용성을 높인다
- 읽기 쉽고 테스트와 유지보수가 용이한 코드를 만든다
- 적절한 수준의 모듈화와 의존성의 방향을 헤쳐서는 안 된다
