9.1 팩토리의 목적 도메인 객체를 생성하는데 복잡한 로직이 들어간다면, '도메인을 잘 표현하기 위한' 도메인 객체의 취지가 무색해진다. 도메인 규칙이 무엇인지 이해하기 어려워지기 때문이다. 아래처럼 Customer 객체를 하나 생성하는데 필요한 로직이 무척 많다면, Customer 클래스를 봤을 때 '어떤 규칙이 있는지' 사실상 알기가 어려워진다. 이런 부분의 개선을 위해 도메인 객체 생성을 위한 팩토리를 도입을 고려하자. public class Customer{ public Customer(){ // DB에서 데이터를 받아온다 // DB에 데이터가 무결성이 문제 없는지 확인한다 // 슬랙이랑 연동해서 확인한다 .... // 수많은 확인 작업. } } 9.2 생성자는 가능한 단순해야 함. 생성자는 가능..
6.1 어플리케이션 서비스란 무엇인가? 서비스 계층에는 어플리케이션 서비스 / 도메인 서비스가 존재함. 도메인 서비스는 도메인 규칙이나 도메인 객체에서 표현하기 애매한 규칙들을 모아놓은 곳임. (사용자 아이디는 특수 문자를 포함할 수 없음) 어플리케이션 서비스는 어플리케이션이 동작하기 위한 동작등을 구현하는 곳임. 사용자 가입, 사용자 탈퇴, 사용자 정보 수정 도메인 명세를 도메인 객체에 코드로 나타낸 것만으로는 어플리케이션이 만들어지지 않는다. 도메인 규칙을 옮겨놓은 것일 뿐이기 때문이다. 동작하는 어플리케이션을 만들기 위해서는 '어플리케이션에서 정의하는 행동'을 구현하는 '어플리케이션 서비스' 계층을 구현해야 한다. 6.2 Usecase 수립하기 → 어플리케이션 서비스 사용자 가입하기 사용자 탈퇴하기..
들어가기 전 이 글은 도메인 주도 설계 철저 입문 4장을 공부하며 작성한 글입니다. 요약 서비스 계층에는 도메인 서비스, 어플리케이션 서비스가 존재함. 도메인 서비스는 도메인 규칙이지만, 도메인 객체 내에 선언하기 애매한 문맥을 표현할 때 사용할 수 있음. 도메인 서비스에 도메인 객체의 모든 규칙을 옮길 수 있으나, 좋지 않음. 도메인 객체는 단순한 값 객체가 되고, 행동(로직)은 모두 도메인 서비스로 분산됨. 로직이 분산되면, 표현력이 떨어지며 변경점을 반영하기 어려움. . (예를 들면 Validation 로직 같은 것들) 도메인 서비스의 각 메서드가 분산된 로직을 각각 사용할 경우, 로직 변경 시 변경 포인트가 너무 많아짐. 도메인 객체에 가급적이면 먼저 모든 로직을 집어넣고, 정말 애매한 로직이 있..
들어가기 전 이 글은 김영한님의 인프런 강의를 복습하며 작성한 글입니다. 외부 설정이란? 하나의 어플리케이션을 여러 환경에서 사용해야 할 때가 있음. (개발, Beta, Release, Rc Phase 등) 각 환경마다 서로 다른 설정값을 사용해야하는 경우가 많음 어떻게 이 문제를 해결할 수 있을까? 가장 단순한 방법 : 각각의 환경에 맞게 어플리케이션을 빌드. 이 방법은 좋은 방법이 아님. 환경에 따라 빌드를 여러 번 해야함. (빌드 결과물이 다름. A-beta.jar, A-rc.jar ) 이 경우, 개발 환경에서 검증이 다 되었다고 생각할 수 있지만 A-rc.jar는 새로운 아티팩트이기 때문에 개발과 똑같이 동작하지 않을 수도 있음. 즉, 유연성이 떨어지는 방법 주로 사용하는 방법 : 빌드는 한번만 ..
요약 리스트 컴프리헨션은 람다식을 사용하지 않기 때문에 람다식을 사용하는 map, filter 대비 가독성이 좋음. 리스트 컴프리헨션을 이용하면 조건식을 이용해 간단히 특정 원소를 스킵할 수 있음. 그러나 map을 사용할 때는 filter 함수의 도움을 받아야 함. 결론은 map, filter를 사용하면 람다 함수를 사용해야 한다. 그런데 람다 함수는 이름을 가지지 않으므로 람다 함수가 무슨 일을 하는지 이해하기 어렵다. 따라서 가독성이 떨어지는 코드가 된다. Item 27. map과 filter 대신 컴프리헨션을 사용하라 # 짝수를 제곱한 값 구하기 a = [1, 2, 3, 4, 5, 6, 7, 8] # 컴프리헨션 이용 even_squares = [x ** 2 for x in a if x % 2 == ..