DDD 프랙티스 #1 자동차 공장 DDD스러운 코드를 작성하는 방법을 탐구하는 자동차 공장 예제. JPA 기반으로 작성한 예제이며 보다 핵심 도메인에 집중할 수 있는 장점이 있음을 확인할 수 있었다. 맨 아래 링크로 가서 README.md와 소스코드를 각각 켜놓고 읽는 것도 괜찮다. (테스트코드 포함) 자동차 공장 설명 Domain 간 유기적인 관계를 크게 이용하지 않는 legacy 예제와 JPA의 여러 옵션을 활용하여 Aggregate 내부의 일관성을 유지하고 도메인에서 핵심이 되는 Aggregate Root등을 파악하기 쉬운 ddd 예제를 작성하였다. 자동차 공장에는 자동차, 바퀴 개념이 존재하는데 자동차 없는 바퀴는 존재하지 않는 것을 전제로 하여 자동차는 Aggregate Root, 바퀴는 자동차..
방법론 검색 결과
DDD Core DDD에서 언급되는 Aggregate Root, Domain Service, Domain Event 등을 코드로 녹여냈다. 예전에 함께 일했던 동료가 작성한 것을 보고 감명 깊었던 적이 있어서 나도 이렇게 코드를 작성해본다. Aggregate Root 특정 Aggregate(애그리거트)에 포함된 Entity끼리는 변경에 대해 일관성(같은 Root를 통해 함께 변경됨)을 가져야 한다. Aggregate의 Root를 담당하는 Entity만 Domain에서 Repository를 유일하게 소유할 수 있어 제어의 창구가 되어 Aggregate 내의 다른 Entity들을 관리한다. AggregateRoot interface를 정의하였는데 이것을 Aggregate Root가 되는 Entity에 붙여서..
DDD (Domain Driven Design) DDD vs OOP? OOP : 패러다임(함수형 등) DDD : 방법론(TDD, BDD 등) DDD와 다른 TDD, BDD의 차이점으로 DDD는 개발자 외에도 기획자, 도메인 전문가 등 프로덕트 팀 단위의 역량이 필요한 협업 방법론이라고 할 수 있음. 객체지향의 역사는 길지만 개인적인 느낌으로는 best practice가 DDD라고 생각되어 정리하게 되었다. DDD 특징 도메인의 모델과 로직에 집중 System, Infrastructure 등 기술적인 부분이 아닌 핵심 도메인 비즈니스에 집중하는 방법론 보편적 언어 사용 프로덕트 팀 구성원이 동일한 언어를 사용 Software Entity와 Domain 간 개념의 일치 코드가 곧 설계를 의미 Entity 클..