TIL

1. 개인정보 수집 유효기간 : 단순 구현
2. DDD 3장 (4,5장 내용 포함)

1. 개인정보 수집 유효기간

단순 구현문제!! 1번으로 나올법하네 ㅋ 하고 봤더니 실제 1번문제였다는 얘기.

알파벳으로 구분되며 1~100의 값을 가지는 각 정책이 있는데, 이는 개인정보를 갖고있는 유효기간(월 단위)을 나타낸다. 각 회원이 가입한 날짜와 회원의 정책, 그리고 오늘의 날짜가 주어졌을 때 개인정보를 파기해야하는지 여부를 따지는 문제였다!

1. 날짜 계산이 가능한가?
2. 주어진 문자열을 적절히 원하는 포맷으로 파싱할 수 있는가?

를 빠른 시간에 파바박! 구현해서 끝내야하는 문제였다.

def add_month(year,month,add):
    month += add
    while (month>12):
        year += 1
        month -= 12
    return year,month

def solution(today, terms, privacies):
    answer = []
    t_year,t_month,t_day = map(int,today.split("."))
    policy = {}
    for t in terms:
        name,month = t.split(" ")
        policy[name] = int(month)
    for i in range(len(privacies)):
        date,term = privacies[i].split(" ")
        ex_year,ex_month,ex_day = map(int,date.split("."))
        ex_year,ex_month = add_month(ex_year,ex_month,policy[term])
        if (t_year<ex_year):
            continue
        if (t_year==ex_year and t_month<ex_month):
            continue
        if (t_year==ex_year and t_month==ex_month and t_day < ex_day):
            continue
        answer.append(i+1)
    return answer

add_month() 함수를 통해 연단위를 넘어가는 개월수에 대해 while문을 돌며 12씩 빼는 작업을 했다! 또, 개인적으로 isExpired() 하나 만들어서 해당 개인정보를 파기해야하는지 여부를 return하게 하고싶었는데.. (코드 아래쪽 if 3개 연달아 나오는 부분) 커찮아서 그냥 깡구현 해버렸다.

코테 공부하면 "어떻게든 돌아가게만 하면 됨ㅋㅋ"에 빠져서 이렇게 되어버리는 것 같다ㅜㅜ 지금 멘토링으로 객체지향을 하고있는데도.

2. DDD 3장 (+ 4,5장)

애그리거트, 그리고 도메인 객체에 대해 설명된 챕터였다. 4,5장은 JPA를 통한 infrastructure의 구현 내용이 있었는데 막 Sort Pageable Specification 등등의 문법을 사용해서 화려하게 객체 조회를 이끌어내는 내용이라 대충 읽었다 ㅜ 사실 오늘 3,4,5,6,7,8,9장을 읽었는데 머릿속에 남는건 많이 없고 중요했던 내용 위주로 다시 한 번만 정리해보고자 한다!

1. 애그리거트 : 상위 수준에서 얽힌 여러 모델들을 한 번에 조망할 수 있게 해주는 방법. 일관성을 갖는 하나의 도메인 군집이라고 생각하면 되며, 같은 애그리거트 안에 속한 모델들은 비슷한 라이프사이클을 갖는다. 도메인 규칙과 요구사항에 맞춰 적절한 애그리거트를 설정하는 것이 중요하다!
2. 애그리거트 루트
   • 애그리거트 전체를 관리할 주체가 되는 루트 엔티티. 하나의 애그리거트(군집)가 가진 일관성이 깨지지 않도록 정책을 설정하고 도메인 기능을 구현한다. 애그리거트의 밸류값은 루트 객체 안에서 적절한 유효성 검사를 거친 뒤 수정하는 것이 좋다.
   • 애그리거트 내부의 여러 객체를 조합하거나, 하위 객체에게 실행을 위임하는 식으로 기능을 구현한다.
   • 이 때 트랜잭션 범위는 작을수록 좋다. 한 애그리거트에서 다른 애그리거트를 수정하지 않게 한다는 의미다. 서로다른 애그리거트는 독립적인 존재이기 때문이다.
3. 리포지터리와 애그리거트 : 리포지토리는 애그리거트 단위로 존재한다. 애그리거트는 하나의 일관성 단위이기도 하므로, 영속화 역시 애그리거트 단위여야하고 리포지터리 메소드는 완전한 애그리거틀를 제공해야한다.
4. ID를 통한 애그리거트 참조 : 애그리거트가 다른 애그리거트를 직접 참조했을 때 몇가지 문제가 존재한다. 따라서 다른 애그리거트를 참조할 땐 ID 참조를 사용하는 것이 좋다.
   • 다른 애그리거트 상태를 쉽게 수정할 수 있다는 점 (해당 애그리거트의 리포지토리 기능 이용)
   • EAGER, LAZY 로딩의 성능 고민을 해야한다는 점
   • 다른 애그리거트의 infrastructure단의 구현체가 달라질 경우, JPA같은 단일 구현체를 사용할 수 없다는 점
5. 애그리거트간 집합 연관 : Collection으로 표현된 관계에서, 1:N은 N쪽에서 1의 엔티티를 참조하는 식으로 구현된다. M:N은 중간에 join table을 두어 1:N을 2개로 쪼개는 식으로 구현한다.
6. 애그리거트를 팩토리로 사용하기 : 애그리거트를 생성할 때, 서비스단에서 직접 생성하면 도메인 로직이 노출될 수도 있으므로 애그리거트(도메인) 단에서 팩토리 메소드를 제공할 수도 있다.

3. DDD 패키지 구조

썩은 필기와 초콜렛

에에... domain, presentation, service, infrastructure 4개의 패키지 구조로 된 프로젝트다. 컨벤션으로 많이들 사용하기 때문에, 처음 보는 프로젝트의 코드가 이같은 패키지 구조를 따르면 반가워 보일지도?

각 영역이 하는 일은 어제 작성했던 글의 설명과 같다. presentation은 사용자 요청 및 응답 포맷을 맞추고, domain은 애그리거트 기능을 구현하기 위한 데이터와 정책을 설정하고, service는 도메인을 이용해 일정한 기능을 수행하고, infrastructure은 실제 기술 구현과 관련된 코드를 다루고..

DDD 패키지 구조에서 가장 중요한 원칙만 가져가자!!

1. 모든 영역에서 domain 영역에 의존할 수 있다.
2. 반대로 domain 영역은 그 어떤 영역에도 의존해선 안된다.
3. 어떤 영역도 infrastructure 영역에 의존해선 안된다.

위와 같은 원칙은, domain영역이 어플리케이션의 정책을 담은 최고수준 모듈이기 때문이며, infrastructure은 실제 기술과 맞닿아있는 최저수준 모듈이기 때문이다. infrastructure에 실제로 구현된 기능이 많기 때문에 해당 객체에 의존하고싶은 유혹이 들 때가 많은데 절대! 그러지 말고 domain에 상위 인터페이스를 추가해 DIP로 사용해야한다고 한다. 이것도 저번에 언급했는데, 기술 때문에 정책이 바뀌고 정책 때문에 기술이 바뀌는 무한나생문참사가 일어날 수 있다고..

REFERENCE

도메인 주도 개발 시작하기 - 최범균
존경하는 멘토님과의 멘토링 시간!!!!