Easy Understanding

옵저버 패턴을 들어가면서 스타크래프트의 옵저버나 언급해야겠다고 생각했는데, 다들 하는 생각이 비슷비슷한 것 같다. 이미 많이들 사용하고 있어서 생각을 접었다. 게다가 난 이 패턴에 옵저버라는 단어가 들어간 순간부터 이해에 방해가 되어 왔다. 대충 개념만 보면 쉬운데 이 옵저버라는 단어 때문에 더 헷갈리는 느낌이다. - 필요 개념: 상속 - 활용도: 부담없이 사용해볼만 함 - 난이도: 간단 - 패턴이 필요한 상황: 일대다 상황 일대다 상황이라 함은, 1개의 원인과 그로 인해 n개의 동작이 수행되어야 하는 상황이다. 예를 들면 다음과 같은 상황이다. - 모니터링 시스템에서 특정 지표가 넘어가면(1) 메시지/메일/카톡 등의 채널로 알림이 발송(n)된다. - 어떤 API를 통해서 요청이 들어왔을 때(1), 동시..

앞으로 패턴들에 대해서 어떻게 백엔드의 관점에서 사용할 것이며, 얼마나 유용할지 평가를 해보려고 한다. 애초에 패턴들을 실용적인 관점에서 검토하지 않으면 의미가 없다는 생각이다. 이 공부가 나의 실무 코드에 도움이 되어야하니 그런 점들을 위해서 정리해두려고 한다. 그러나 딱 내 학습 수준에 맞는 평가가 나올 것 같아서 그 점은 참고해야 한다. 추가로 디자인 패턴의 개념에 대한 기초 설명은 패스하려고 한다. 전략 패턴 - 필요 개념: 컴포지션 - 활용도: 부담없이 사용해볼만 함 - 난이도: 간단 - 패턴이 필요한 상황: 상속 상황에서 내부 코드의 빈번한 중복 보통 이 패턴에 가장 많이 나오는 예제는 Duck에 대한 예제이다. quack, fly 메서드가 나오고 여러 오리종류가 나오는 그 예제다. 헤드퍼스트..

헤드퍼스트 디자인 패턴에서는 다음과 같은 13가지 패턴을 다루고 있다. 1. 전략 패턴 2. 옵저버 패턴 3. 데코레이터 패턴 4. 팩토리 패턴(팩토리 메서드, 추상 팩토리) 5. 싱글턴 패턴 6. 커맨드 패턴 7. 어댑터 패턴 8. 파사드 패턴 9. 템플릿 메서드 패턴 10. 반복자 패턴 11. 컴포지트 패턴 12. 상태 패턴 13. 프록시 패턴 디자인 패턴은 이외에도 다양하며, 다음의 링크에서 대부분의 패턴들을 확인할 수가 있다. 해당 링크가 가장 잘 정리되어 있는 것 같아서 종종 참고하고는 한다. https://refactoring.guru/design-patterns/catalog The Catalog of Design Patterns refactoring.guru 디자인 패턴은 크게 다음과 같이..

DDD 학습을 하다보면 전략적 패턴(도메인을 도출하고 정의하는 과정)에는 어느 정도 일관된 결론이 있는 것을 확인할 수 있다. 각종 DDD 책이나 블로그 들에서 해당 과정은 타협할 수 없는 과정으로 여겨지고 있고, 실제로 어떤 문서를 읽어도 내용들이 크게 다르지는 않다. 하지만 전술적 패턴(실제로 코드를 작성하고 아키텍처를 결정하는 과정)에 대해서는 딱히 일관성이 없다. 왜냐하면 DDD에서는 코드를 작성하는 방법에 대해서 정답이 없다고 애초에 선언되었기 때문이다. 실제 DDD 예제 코드들을 깃헙에서 확인해보니, 정말 제각각의 다양한 형식의 코드 스타일들이 존재했다. 반 버논의 iDDD 책에서 제공하는 DDD에 대한 방법론은 많은 인사이트를 제공해주었지만, 실제로 고민해보고 코딩해보는 과정이 필요하다고 생..

DDD의 가장 큰 장점 중 하나는 특정 아키텍처의 사용을 요구하지 않는다는 점이라고 한다. 하지만 책을 읽고 공부를 하다보면, 사실상 DDD에서 선택할 수 있는 괜찮은 아키텍처는 결국은 몇개 안 된다. 가장 간단한 것부터 순서대로 정리해 볼 것이다. 1. Layered Architecture 레이어드 아키텍처는 패턴계에서는 할아버지 같은 존재다. 이름 그대로 프로그램 내에서 계층을 나누는 설계 방식이다. 스프링의 예시가 가장 대표적이다. Controller - Service - Domain - Repository 위와 같은 개발 방식은 레이어드 아키텍처의 대표적인 예시다. 의존의 방향성은 오로지 위에서 아래로만 내려간다. public class UserController{ @Autowired privat..

이전까지는 DDD의 도메인 / 컨텍스트를 어떻게 클래스로 구현하는지 정리했다면, 이번에는 이런 도메인 객체들을 이용하는 방법과 도움이 되는 요소들에 대해서 간단하게 정리하려고 한다. 여러 도메인 로직을 엮거나 변환하는 등 도메인 로직을 조작하는데 활용하는 '도메인 서비스' 실제 사용자의 유스케이스, 유저 인터페이스 로직을 구현하는 '어플리케이션 서비스' new로 객체를 생성하지 않고 대리 생성을 담당하는 메서드인 '팩토리' 그리고 이런 것들을 어떻게 자바 '패키지'로 구분하는지 에 대해서 정리해보았다. 이전에는 애그리거트 내부에서 도메인 로직을 구현했으니, 이번에는 위의 4가지 방법들을 이용해서 도메인 로직을 외부에 제공하는지까지 확인하게 될 것이다. 1. 도메인 서비스 DDD의 Service는 스프링에..

지금까지 DDD 설명에서는 도메인이라든지 바운디드 컨텍스트라든지 개념적인 것들을 다뤘다면, 이제부턴 실전 코딩이다. 데이터 중심의 개발에서 DB에 대응하는 Class들을 만들었던 것처럼, Domain에 대응하는 Class들을 만드는 과정이 필요하다. 이제부터는 각 도메인들을 Class로 표현해보기 위한 개념과 코드를 구경할 차례다. 1. 엔터티(Entity) @Entity public class Movie { @Id private Long id; private String name; private Long playTimestamp; private String directorName; ... public void changeMovieName(){ ... } public void fireAndHireNewD..

도메인과 바운디드 컨텍스트는 무엇이길래 이전 글에서도 이야기 했지만, DDD는 용어부터가 우리가 알고있는 것과 다르고, 익숙해져야 할 것들이 많다. 특히나 바운디드 컨텍스트(Bounded Context)에 대해서는 초반에 감이 잘 오지 않았던 것 같다. 시작전에 간단하게 요약을 해보자면, DDD는 전략적(Strategic) 설계와 전술적(Tactical) 설계로 나뉜다. - 전략적 설계: 개념적으로 도메인과 바운디드 컨텍스트를 정의하고, 유비쿼터스 용어를 정리하는 부분 - 전술적 설계: 세부 아키텍처와 코드의 구현과 관련된 부분 이라고 보면 되는데, 이 글에서 다루는 것이 전략적 설계의 핵심적인 부분이라고 보면 된다. 조금씩 다르지만 대략적으로 아래의 순서로 전략적 설계가 진행된다고 보면 된다. 1. 도..