본문 바로가기

더 나은 엔지니어가 되기 위해

(80)
도메인 주도 설계 철저 입문 5부 - 아키텍처와 앞으로의 학습 이 글은 도메인 주도 설계 철저 입문 (위키북스) 를 읽고 개인적으로 정리한 글입니다. 0. 들어가며 이번 글에서는 DDD와 함께 자주 언급되는 아키텍처에 대해 다룬다. 책에서는 아키텍처에 대해 다음처럼 소개하고 있다. 아키텍처는 간단히 말해 코드를 구성하는 원칙이다. 코드가 어디에 배치돼야 하는지에 대해 답을 명확히 제시하며, 로직이 무질서하게 흩어지는 것을 막는다. 개발자는 아키텍처가 제시하는 원칙에 따르면서 "어떤 로직을 어디에 구현할 것인지"를 고민하지 않아도 된다. 이로써 개발자가 DDD의 본질인 "도메인을 파악하고 표현하는 것"에 집중할 수 있게 해 준다. DDD에서 아키텍처 역할의 핵심은 "도메인 객체"를 지켜내는 것이다. 이것이 가능하다면 다음 아키텍처 중 어떤 것을 사용해도 무방하다. 계..
도메인 주도 설계 철저 입문 4부 - 지식 표현을 위한 고급 패턴 이 글은 도메인 주도 설계 철저 입문 (위키북스) 를 읽고 개인적으로 정리한 글입니다. 0. 들어가며 이번 글에서는 책에서는 고급 패턴이라고 표현되어 있는, 도메인을 더 잘 표현할 수 있는 방법들을 배운다. 1. 애그리게이트 (Aggregate) 1.1. 애그리게이트 예시 먼저 다음 예시를 보자. @dataclass class User: id: UserId = field(init=False, default_factory = UserId) name: UserName = field(compare=False) User 라는 엔티티 객체(Entity)는 UserId 와 UserName 이라는 값 객체(Value Object) 로 구성되어 있다. 여기서 User, UserId, UserName 이라는 3개의 객체..
도메인 주도 설계 철저 입문 3부 - 애플리케이션을 만들기 위한 패턴 이 글은 도메인 주도 설계 철저 입문 (위키북스) 를 읽고 개인적으로 정리한 글입니다. 0. 들어가며 이전 글까지는 도메인 모델을 표현하는 방법과 이를 도메인 모델을 다루는 방법을 배웠다. 이번 글에서는 본격적으로 애플리케이션을 만들기 위한 패턴을 배운다. 즉 이제 만들어 놓은 "값 객체", "엔티티" 그리고 "서비스"를 실제 유저의 관점에서 사용할 수 있도록 유스케이스를 하나씩 만들어나가는 것이다. 1. 리포지토리 (Repository) 1.1. 리포지토리의 역할 리포지토리의 일반적인 의미는 "보관창고"다. 이런 의미에 맞게, 리포지토리 객체는 데이터를 저장하고 필요시 다시 복원하는 역할을 한다. 쉽게 말해 DB와 연결하여 데이터를 DB에 저장하고, 불러오는 일을 맡는다고 생각하면 된다. 다만, 꼭 D..
도메인 주도 설계 철저 입문 2부 - 지식 표현을 위한 패턴 이 글은 도메인 주도 설계 철저 입문 (위키북스) 를 읽고 개인적으로 정리한 글입니다. 0. 들어가며 이번 글에서는 도메인 지식을 어떻게 표현할 것인지에 대한 방법을 배운다. 크게 3가지를 다룬다. 값 객체 (Value Object) 엔티티 (Entity) 도메인 서비스 (Domain Service) 1. 값 객체 (Value Object) 1.1. 값 객체 예시 보통 프로그래밍 언어에는 원시 타입(Primitive) 자료형이 있다. 그리고 이를 이용해 여러 값들을 표현할 수 있다. 예를 들면, "이름"은 다음처럼 string 으로 표현할 수 있다. full_name = "jeon heumsi" 그러나, DDD에서는 이처럼 원시 타입을 사용하지 않고, 도메인에 맞는 객체로 정의해 사용한다. class F..
도메인 주도 설계 철저 입문 1부 - 들어가며 & 목차 이 글은 도메인 주도 설계 철저 입문 (위키북스) 를 읽고 개인적으로 정리한 글입니다. 들어가며 평소 궁금해했던 도메인 주도 설계, 일명 DDD 관련 책이 최근에 나와 읽어보았다. 도메인 주도 설계는 에릭 에반스님의 책이 고전으로 가장 유명한데, 사실 이 책을 읽을 엄두가 안났다. 늘 그렇듯 고전 자체를 읽기란.. 분량도 그렇고, 뭔가 시작부터 쉽지 않기 때문이다. 그러던 차, 나같은 입문자를 위한 "도메인 주도 설계 철저 입문" 이라는 책이 아주 따끈따근하게 나왔으니, 이 책부터 가볍게 읽어보면, DDD에 어렵지 않게 접근할 수 있겠다 싶었다. 분량은 약 350페이지 가량되는데, 내용이 "입문"이라는 단어에 딱 맞게 어렵지 않아 금방 읽는다. 나는 다 출퇴근 + 주말에 읽는데 약 2주가량 걸린 거 같다..
파이썬으로 구현하는 클린 아키텍쳐 - rentomatic 0. 들어가며 클린 아키텍처 책을 읽고 나서도, 실제로 구현하지 않고는 이를 구체적으로 체감하기 어렵다는 생각이 들었다. 그래서 생각나는대로 스스로 구현해보았다. 무려 일주일이나 고민 고민하며 만들었다. 그래도, 맘에 들지 않았다. 솔직히 내가 구현한게 올바른 지에 대해서 확신이 없었다. 인터넷을 뒤적거리며 클린 아키텍처를 파이썬으로 구현하는 자료를 찾아보았다. 그중 발견한 블로그 글. 매우 세세하게 설명되는 데 양이 꽤 길다. 더 찾아보니 이 글을 쓴 사람이 leanpub에 책을 내신 것을 알게 되었다. 무료다. 180페이지 조금 안되는데, 생각보다 읽어볼 만한 것 같았다. 이 글은 이 책을 읽고 클린 아키텍처를 구현하는 핵심만 정리한 글이다. 책 자체는 TDD 방식으로 구현을 진행하는데, 이게 무료인..
클린 아키텍처 5부 - 아키텍처 이 글은 로버트 C. 마틴의 클린 아키텍처를 읽고 나름대로 중요하다고 생각한 부분만 정리한 글이다. 들어가며 이번 5부에서부터는 본격적으로 아키텍처에 대한 이야기가 나온다. 사실 대부분의 내용이 이미 잘 정리되어 인터넷 여기저기에 공유가 되어있다. (충분히 잘 정리된 글이 많아서 그런지, 굳이 내가 더 정리해야 하나 싶기도 하고... ) 여하튼, 일단 시작해본다.. 아키텍처란? 거두절미하고 아키텍처와 관련된 설명만 짤막하게 간추려 본다. 좋은 아키텍처는 시스템을 쉽게 (이해하고, 개발하며, 유지보수하고, 배포)할 수 있게 한다. 아키텍처는 시스템의 동작 여부 자체와는 거의 관련이 없다. 아키텍처는 소프트웨어를 유연하고 부드럽게 구조화한다. 좋은 아키텍트는 시스템의 핵심적인 요소(정책이라고 한다)를 식별하..
클린 아키텍처 4부 - 컴포넌트 이 글은 로버트 C. 마틴의 클린 아키텍처를 읽고 나름대로 중요하다고 생각한 부분만 정리한 글이다. 들어가며 이전 부서에서 SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법을 알려준다면, 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 알려준다. 큰 빌딩과 마찬가지로, 대규모 소프트웨어 시스템은 작은 컴포넌트들로 만들어진다. 컴포넌트 컴포넌트는 배포 단위다. 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 라고, 책에 써져있기는 한데. 솔직히 말해서 이게 무슨 말이지 싶었다. 배포 단위면 컨테이너 이미지 정도를 말하는 건가? 솔직히 말해 나는 와 닿지 않아, CBD에 관한 글을 참고하며 이해했다. 내가 생각한 컴포넌트는 "사용 가능한 단위"다. 즉 실행 가능한 소스 코드 뭉치고, 이를 사용할 수 있..