코드메모장

작성 목적

해당 게시글은 DDD관련하여 공부를 하던 중 개인적으로 모르거나 햇갈리는 용어에 대해 리마인드 하기 위해 요약한 내용입니다.

잘못 이해하고 있는 내용이 있으면 댓글로 남겨주시면 감사하겠습니다.

(DDD관련 학습을 진행하는 동안 지속적으로 업데이트 할 예정)

용어

• 도메인 주도 설계(DDD(Domain-Driven Design))
  • 복잡한 소프트웨어를 설계 및 개발하는 과정에서 핵심적인 비지니스 개념과 비지니스 논리 중심으로 설계하는 방법
• 도메인 전문가
  • 특정 분야나 사업에 대해 깊이있는 지식과 경험을 가진 사람
• 개념모델 vs구현 모델
  • 개념모델 : "무엇"을 할 것인지에 대한 전략적 설계를 제공
  • 구현모델 : "어떻게" 실행할 것인지에 대한 실용적인 가이드를 제공
• 유비쿼터스 언어 (보편언어)
  • 팀원 모두가 동일하게 이해하고 표현하는 공통적인 언어

참고 자료

• 도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지
• ChatGPT 4.0

(1) @InitBinder 이란?

• WebDataBinder를 초기화 하는 메소드를 지정할 수 있는 설정을 제공합니다.
• 특정 컨트롤러에서 바인딩 또는 검증 설정을 변경하고 싶을 때 사용합니다.
• 모든 요청 전 InitBinder를 선언한 메소드가 실행됩니다.

(2) 사용법

• Controller

  @RestController
  public class MemberController {
  
  	private final MemberService memberService;
  	private final MemberLoginRequestValidator memberLoginRequestValidator;
      
      @Autowired
      public MemberController(MemberService memberService, MemberLoginRequestValidator memberLoginRequestValidator){
      	this.memberService = memberService;
          this.memberLoginRequestValidator = memberLoginRequestValidator;
      }
  
      //memberLoginRequestDto 객체로 요청이 들어올 경우 memberLoginRequestValidator를 우선 실행
      @InitBinder("memberLoginRequestDto")
      public void loginBinder(WebDataBinder webDataBinder){
          webDataBinder.addValidators(memberLoginRequestValidator);
      }
      
      //로그인
      @PostMapping("/api/member/login")
      public ResponseEntity<Map<String,String>> memberLogin(@Valid @RequestBody MemberLoginRequestDto memberLoginRequestDto, HttpServletResponse httpServletResponse){
  
          return ResponseEntity.ok(memberService.memberLogin(memberLoginRequestDto, httpServletResponse));
      }
  }

• Validator

  @Component
  public class MemberLoginRequestValidator implements Validator {
  
      private final MemberRepository memberRepository;
      private final PasswordEncoder passwordEncoder;
  
      public MemberLoginRequestValidator(MemberRepository memberRepository, PasswordEncoder passwordEncoder){
          this.memberRepository = memberRepository;
          this.passwordEncoder = passwordEncoder;
      }
  
      @Override
      public boolean supports(Class<?> clazz){
          return clazz.isAssignableFrom(MemberLoginRequestDto.class);
      }
  
      @Override
      public void validate(Object object, Errors errors){
          MemberLoginRequestDto memberLoginRequestDto = (MemberLoginRequestDto) object;
  
          if(!memberRepository.existsById(memberLoginRequestDto.getEmail())){
              errors.rejectValue("email", "invalid.email", "존재하지 않는 email입니다.");
          } else {
              MemberEntity memberEntity = memberRepository.getById(memberLoginRequestDto.getEmail());
              if(!passwordEncoder.matches(memberLoginRequestDto.getPassword(), memberEntity.getPassword())) {
                  errors.rejectValue("password","invalid.password", "패스워드가 일치하지 않습니다.");
              }
          }
      }

(1) @Data 어노테이션이란?

• @Data = @toString + @getter + @setter + @RequiredArgsConstructor + @EqualsAndHashCode
• @toString - toString() 메서드를 생성한다. @ToString(exclude = {"제외값"})으로 제외시키고 싶은 값을 설정할 수 있다.
• @getter/setter - getter(), setter() 메서드를 생성한다.
• @RequiredArgsConstructor - 초기화 되지 않은 모든 final 필드, @NonNull과 같이 제약조건이 설정되어있는 모든 필드들에 대한 생성자를 자동으로 생성한다.
• @EqualsAndHashCode - equals(), hashCode() 메서드를 생성한다.

(2) 문제점

• @RequiredArgsConstructor 어노테이션으로 문제가 발생할 수 있다. 예를 들어 인해 두 개의 타입 인스턴스 멤버를 선언한 상황에서 개발자가 선언된 인스턴스 멤버의 순서를 바꾸면, 개발자도 인식하지 못하는 사이에 lombok이 생성자의 파라미터 순서를 필드 선언 순서에 따라 변형하게 된다. 이때, IDE가 제공해주는 리팩토링은 전혀 동작하지 않고, 두 필드가 동일 타입이기 때문에 기존 소스에서도 오류가 발생하지 않아 아무런 문제없이 동작하는 것으로 보이지만, 실제로 입력된 값이 바뀌어 들어가는 상황이 발생한다.

출처 - https://velog.io/@leyuri/Spring-boot-JPA-%EC%96%B4%EB%85%B8%ED%85%8C%EC%9D%B4%EC%85%98-Entity-Table-Column-Id-Lombok

(1) 영속성 컨텍스트 (Persistence Context)란?

• 영속성 컨텍스트는 엔티티를 영구 저장하는 환경입니다.
• 영속성 컨텍스트는 눈에 보이지 않는 논리적인 개념입니다.

(2) 영속성 컨텍스트 (Persistence Context) 특징

• @Id 어노테이션을 통해 엔티티를 식별합니다.
• 1차 캐시가 있습니다. Entity가 DB에 저장되기 전에 사용되는 공간인데, 반대로 DB를 조회하더라도 1차캐시에 저장하게 됩니다. 따라서 같은 Entity를 읽고자 할 때 빠른 읽기 기능을 제공하고 부하를 줄여줍니다. DB에 저장할 때 역시 1차 캐시에 저장됨으로써 중간에 수정할 사항이 있다면 UPDATE쿼리를 사용하지 않고도 INSERT쿼리만으로 바로 저장할 수 있습니다.
• 위 처럼 캐시에 있는 것과 실제 DB에 존재하는 것이 동일하기 때문에 객체의 동일성을 보장합니다.
• 트랜잭션을 지원하는 쓰기지연 기능이있습니다. 즉 값을 변경하자마자 바로 DB에 반영하는 것이 아니라, 영속성 컨텍스트 내부의 SQL 저장소에 생성 쿼리를 저장 해둡니다. 이 후 commit을 하게 되면 저장해두었던 쿼리를 데이터베이스에 보냅니다.
• 엔티티 매니저는 find(조회), persist(추가), remove(삭제)만 있으며 update() 메서드는 존재하지 않는데 그 이유는 변경 감지(dirty checking)를 하기 때문입니다. 변경 감지가 가능한 이유는 1차 캐시에 최초로 저장될 때 그 상태를 스냅샷을 해 두었다가 영속성 컨텍스트와 DB사이의 동기화가 이루어지는 flush 시점에서 스냅샷과 현재 엔티티의 상태를 비교하여 엔티티가 변경되었다면 UPDATE 쿼리를 실행합니다.

참조 - http://blog.neonkid.xyz/233, https://victorydntmd.tistory.com/207

(1) String, StringBuffer, StringBuilder란?

• 자바에서 문자열을 다루는 클래스이다.

(2) String, StringBuffer, StringBuilder 차이점은?

• String - 한번 생성되면 할당된 메모리 공간이 변하지 않습니다. + 연산자 또는 concat 메서드를 통해 기존에 생성된 String 클래스 객체 문자열에 다른 문자열을 붙여도 기존 문자열에 새로운 문자열을 붙이는 것이 아니라, 새로운 String 객체를 만든 후, 새 String 객체에 연결된 문자열을 저장하고, 그 객체를 참조하도록 합니다.
• StringBuffer, StringBuilder - 크기가 유연하게 변하는 가변적인 특성을 가지고 있으며 제공하는 메서드도 같고 사용하는 방법도 동일합니다. 하지만 두 클래스는 동기화 지원의 유무가 다릅니다. StringBuffer는 각 메서드 별로 synchronized keyword가 존재하여 멀티 스레드 상태에서 동기화를 지원하고 StringBuilder는 단일 스레드 환경에서만 사용하도록 설계되어 있습니다. StringBuilder가 StringBuffer보다 속도는 더 빠르지만 현업에서는 언제 멀티스레드 환경에서 돌아가지 알지 못하기에 안정적인 StringBuffer로 통일하여 코딩하는것이 좋습니다.

참조 - https://ifuwanna.tistory.com/221, https://coding-factory.tistory.com/546

(1) Collection 이란?

• 다수의 데이터를 쉽고 효과적으로 처리할 수 있는 표준화된 방법을 제공하는 클래스의 집합을 의미한다.
• List, Map, Set 인터페이스를 기준으로 여러 구현체가 존재한다. 이에 더해 Stack과 Queue 인터페이스도 존재한다.

(2) Collection 장점

• 클래스들을 제공해 주기 때문에 데이터 구조를 직접 구현하지 않고 사용하기 편하다.
• 배열과는 다르게 객체를 보관하기 위한 공간을 미리 정하지 않아도 된다. (동적 메모리 할당)

(3) Collection 인터페이스

• List - 순서가 있으며 중복을 허용한다.
• Set - 순서가 중요하지 않고 중복을 허용하지 않는다.
• Map - 키(Key)-값(Value) 으로 이루어져 있으며 키는 중복을 허용하지 않지만 값은 중복을 허용한다.
• Stack - 나중에 들어온 데이터가 먼저 출력되는 LIFO 형태이다.
• Queue - 먼저 들어온 데이터가 먼저 출력되는 FIFO 형태이다.

참조 - https://en.wikipedia.org/wiki/Java_collections_framework

(1) Spring 프레임워크란?

• 자바 플랫폼을 위한 오픈소스 애플리케이션 프레임워크로서 엔터프라이즈급 애플리케이션을 개발하기 위한 모든 기능을 종합적으로 제공하는 경량화된 솔루션입니다. Spirng Framework는 경량 컨테이너로 자바 객체를 담고 직접 관리합니다. 객체의 생성 및 소멸 그리고 라이프 사이클을관리하며 언제든 Spring 컨테이너로 부터 필요한 객체를 가져와 사용할 수 있습니다. 이는 Spirng이 IOC 기반의 Framework임을 의미합니다.
• 엔터프라이즈급 개발이란 뜻대로만 풀이하면 기업을 대상으로 하는 개발이라는 말입니다. 즉, 대규모 데이터 처리와 트랜잭션이 동시에 여러 사용자로 부터 행해지는 매우 큰 규모의 환경을 엔터프라이즈 환경이라 일컫습니다.

(2) Spring 프레임워크의 주요 특징

• IOC(제어의 반전)
  • 스프링의 가장 중요하고 핵심적인 기능으로서 자바의 반영(reflection)을 이용해서 객체의 생명주기를 관리하고 의존성 주입(Dependency Injection)을 통해 각 계층이나 서비스들간의 의존성을 맞춰준다. 이러한 기능들은 주로 환경설정을 담당하는 XML 파일에 의해 설정되고 수행된다.
• AOP(관점 지향 프로그래밍)
  • 대부분 소프트웨어 개발 프로세스에서 사용하는 방법은 OOP(Object Oriented Programming) 입니다. OOP는 객체지향 원칙에 따라 관심사가 같은 데이터를 한곳에 모아 분리하고 낮은 결합도를 갖게하여 독립적이고 유연한 모듈로 캡슐화를 하는 것을 일컫습니다. 하지만 이러한 과정 중 중복된 코드들이 많아지고 가독성, 확장성, 유지보수성을 떨어 뜨립니다.
  • AOP에서는 핵심기능과 공통기능을 분리시켜 핵심 로직에 영향을 끼치지 않게 공통기능을 끼워 넣는 개발 형태 이며 이렇게 개발함에 따라 무분별하게 중복되는 코드를 한 곳에 모아 중복 되는 코드를 제거 할 수 있어지고 공통기능을 한 곳에 보관함으로써 공통 기능 하나의 수정으로 모든 핵심기능들의 공통기능을 수정 할 수 있어 효율적인 유지보수가 가능하며 재활용성이 극대화됩니다. 물론 AOP로 만들 수 있는 기능은 OOP로 구현 할 수 있는 기능이지만 Spring에서는 AOP를 편리하게 사용 할 수 있도록 이를 지원하고 있습니다.

• POJO(Plain Old Java Object)
  • 이전 EJB(Enterprise JavaBeans)는 확장 가능한 재사용이 가능한 로직을 개발하기 위해 사용 되었었는데 EJB는 한가지 기능을 위해 불필요한 복잡한 로직이 과도하게 들어가는 단점이 있었습니다. 그래서 다시 조명을 받은게 POJO입니다. POJO는 gettet/setter를 가진 단순 자바 오브젝트로 정의를 하고 있습니다. 이러한 단순 오브젝트는 의존성이 없고 추후 테스트 및 유지보수가 편리한 유연성의 장점을 가집니다. 이러한 장점들로 인해 객체지향적인 다양한 설계와 구현이 가능해지고 POJO의 기반의 Framework가 조명을 받고 있습니다.
• MVC 패턴
  • 스프링은 웹 프로그램밍 개발 시 거의 표준적인 방식인 Spring MVC라 불리는 모델-뷰-컨트롤러(MVC) 패턴을 사용한다. DispatcherServlet이 Controller 역할을 담당하여 각종 요청을 적절한 서비스에 분산시켜주며 이를 각 서비스들이 처리를 하여 결과를 생성하고 그 결과는 다양한 형식의 View 서비스들로 화면에 표시될 수 있다.
  • Model
    
    • Model에서는 데이터처리를 담당하는 부분입니다. Model부분은 Serivce영역과 DAO영역으로 나누어지게 되고 여기서 중요한 것은 Service 부분은 불필요하게 HTTP통신을 하지 않아야하고 request나 response와 같은 객체를 매개변수로 받아선 안된다. 또한 Model 부분의 Service는 view에 종속적인 코드가 없어야 하고 View 부분이 변경되더라도 Service 부분은 그대로 재사용 할 수 있어야 한다.Model에서는 View와 Controller 어떠한 정보도 가지고 있어서는 안된다.
  • View
    
    • View는 사용자 Interface를 담당하며 사용자에게 보여지는 부분입니다. View는 Controller를 통해 모델에 데이터에 대한 시각화를 담당하며 View는 자신이 요청을 보낼 Controller의 정보만 알고 있어야 하는 것이 핵심이다. Model이 가지고 있는 정보를 저장해서는 안되며 Model, Controller에 구성 요소를 알아서는 안된다.

• • Controller
    
    • Controller에서는 View에 받은 요청을 가공하여 Model(Service 영역)에 이를 전달한다. 또한 Model로 부터 받은 결과를 View로 넘겨주는 역할을 합니다. Controller에서는 모든 요청 에러와 모델 에러를 처리하며 View와 Controller에 정보를 알고 있어야한다. Model과 View의 정보에 대해 알고 있어야한다.
• 트랜잭션 지원
  • 데이터베이스를 연동하여 사용할 때 발생할 수 있는 문제를 해결하기 위해 트랜잭션 처리를 해주어야 한다. 스프링에서는 이러한 트랜잭션 처리를 어노태이션이나 xml로 설정할 수 있도록 지원해준다.
• 일괄처리
  
  • 스프링은 특정 시간대에 실행하거나 대용량의 자료를 처리하는데 쓰이는 일괄 처리(Batch Processing)을 지원하는 배치 프레임워크를 제공한다. 기본적으로 스프링 배치는 Quartz 기반으로 동작한다.

참조 - https://ko.wikipedia.org/wiki/%EC%8A%A4%ED%94%84%EB%A7%81_%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC, https://khj93.tistory.com/entry/Spring-Spring-Framework%EB%9E%80-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-%ED%95%B5%EC%8B%AC-%EC%A0%95%EB%A6%AC

(1) WIL(Weekly I Learned) - 14마지막 주차

• 모든 일정을 끝내고 이력서, 포트폴리오, 자기소개서를 작성하는 주차가 되었습니다.
• 기본적인 포맷은 주어지며 항해99를 하면서 또는 개인적인 경력을 개개인이 작성하는 방식으로 진행됩니다.

(2) 일정

• 5/29 ~ 6/4 - 이력서, 포트폴리오 작성 및 모의면접 자기소개서 작성
• 6/3 ~ 4 - 협력사(일부) 모의면접 
• 6/4 18:00 - 항해99 수료식
• 6/5 제출마감, 6/7 ~ 6/9 오후 예정 - 이력서/포트폴리오/자소서 리뷰(제출인원 한에서 3개씩 뽑아 전체적인 피드백 할 예정)
• 6/9 19:00 ~ 20:00 - 김병욱 멘토님 취업꿀팀 특강
• 6/9 - 모의면접 서면 피드백 공유
• 6/14 18:00 까지 - 3차 협력사 라인 지원
• 6/21 18:00 까지 - 2차 협력사 라인 지원
• 6/28 18:00 까지 - 1차 협력사 라인 지원

(3) 수료증 및 상장

(4) 느낀점

• 모의면접을 한번 경험함으로써 '아직 부족한 점이 많구나'라는 것을 깨달았습니다. 지금까지 프로젝트를 진행하면서 만드는것에는 익숙해져 있지만, 이론적으로 어떻게 돌아가는지에대해 공부해야할 필요성을 느꼇으며 항해99가 끝나더라도 열심히하는 항해99 멤버들과 이어서 공부를 하기로 하였습니다.
• 수료식 당일 항해99 크루원 분들의 투표를 통해 여러 분야의 상장받을 분들이 선정되었습니다. 그중에 하나의 상을 받아 지금까지 열심히 했구나 느낄수 있어 좋았고 알아주신분들이 있다니 너무 감사드립니다.
• 이력서, 포트폴리오, 자기소개서도 중요하지만 코딩테스트, 기술면접도 매우 중요하기에 앞으로 원하는 곳을 위해 열심히 노력하겠습니다.

(1) WIL(Weekly I Learned) - 13주차

• 이전 9주차 ~ 13주차 까지는 최종 프로젝트를 이어 진행합니다.
• 프론트(React) 3분 백엔드(Spring) 3분 디자이너 1분으로 최종 프로젝트를 진행합니다.
• MVP가 완성되어 배포 후 유저 피드백을 받고 유지보수를 하고있습니다.

(2) 일정

• 5/25 4조(10:45 ~ 11:00) - 1차 리허설 
• 5/26 19:00 ~ 20:00 - 핵클 협력사 발표
• 5/26 20:00 ~ 21:00 - 이큐브랩 협력사 발표
• 5/28 14:00 ~ 14:30 - 자가리허설
• 5/28 15:00 ~ 17:00 - 협력사 초청 발표회

(3) 배운점

• 최종 프로젝트 유지보수(크롤링 수정)
• Traivs CI(개인공부)
• AWS CodeDeploy(개인공부)

(4) 최종 프로젝트

• 주제 - 퇴근하고 뭐하지?
  • 퇴근 후 취미를 찾을 수 있는 사이트 들을 한번에 보고 필터처리 할 수 있도록 도와주는 사이트입니다.
• 사이트
  • 퇴근하고 뭐하지 - https://afterwork.co.kr/
• Git
  • 프론트 엔드 - github.com/greedysiru/gaemangtalk_frontend
  • 백엔드 - github.com/seongbinko/afterwork
  • 백엔드 크롤링 - github.com/seongbinko/afterwork-scheduler
• 영상
  • 중간점검 시연 영상 - https://www.youtube.com/watch?v=WeymerrTyMw
  • 시연 최종 영상 - https://www.youtube.com/watch?v=pW9s6w0tXzg

(5) 느낀점

• 드디어 최종 프로젝트까지 잘 마무리되었습니다. 여러 피드백이 있었고, 크롤링 대상인 사이트 UI가 바뀌는 등 생각지도 못한 부분에서 코드 수정이 필요하여 당황하였습니다. 그래도 처음 크롤링을 만들때 처럼 하나하나 로그를 찍어가며 문제 없이 수정하여 이런게 유지보수인가? 라는 생각이 들었습니다.
• 개발자 6명, 디자이너 1명을 이루어져 앞으로 경험하기 힘든 너무 값진 경험이였고, 좋게 마무리가 되어 안심이되었습니다.
• 다음주엔 협력사들과의 모의면접 및 이력서 제출만 남았습니다. 마지막 주차인만큼 더 열심히 하여 마무리를 열심히하겠습니다.

(1) WIL(Weekly I Learned) - 12주차

• 이전 9주차 ~ 13주차 까지는 최종 프로젝트를 이어 진행합니다.
• 프론트(React) 3분 백엔드(Spring) 3분 디자이너 1분으로 최종 프로젝트를 진행합니다.
• MVP가 완성되어 배포 후 유저 피드백을 받고 유지보수를 하고있습니다.

(2) 일정

• 5/13 자정까지 - 팀 별 중간 결과물 제출
• 5/15 18:00 ~ 19:00 - 마케팅 특강
• 5/19 19:00 ~ 20:00 - 데이터라이즈 협력사 발표
• 5/19 20:00 ~ 21:00 - 스토리시티 협력사 발표
• 5/21 - 팀별 면담
• 5/26 - 1차 모의발표
• 5/27 - 2차 모의발표 및 녹화

(3) 배운점

• SonarLint 정적 분석도구 사용법
• jacoco(java code coverage tools) 사용법
• 쓰레드 관리
  • ExecutorService
  • Executors
  • Future
  • Runnable

(4) 최종 프로젝트

• 주제 - 퇴근하고 뭐하지?
  • 퇴근 후 취미를 찾을 수 있는 사이트 들을 한번에 보고 필터처리 할 수 있도록 도와주는 사이트입니다.
• 사이트
  • 퇴근하고 뭐하지 - https://afterwork.co.kr/
• Git
  • 프론트 엔드 - github.com/greedysiru/gaemangtalk_frontend
  • 백엔드 - github.com/seongbinko/afterwork
  • 백엔드 크롤링 - github.com/seongbinko/afterwork-scheduler
• 영상
  • 중간점검 시연 영상 - https://www.youtube.com/watch?v=WeymerrTyMw

(5) 느낀점

• 피드백을 받으면서 사람마다 보는 눈, 원하는 느낌이 많이 다르다는 것을 느꼇습니다.
• 마케팅을 하면서 유저개입이 어렵게 되는것을 많이 느꼇으며 유저들이 들어오더라도 설문참여율이 엄청나게 저조한것을 보고 서비스를 운영하는것이 힘든거구나 다시한번 깨달았습니다.
• SonarLint를 사용하면서 내 코드내에서 불필요한 부분을 많이 알 수 있어 코드를 개선할 수 있어 좋았습니다.
• 매일 크롤링을 돌리는 시간이 100분 정도의 소요되었습니다. 스파르타 코딩클럽 대표님께서 스레드를 사용하여 시간개선을 할 수 있다고 알려주셔서 사용한 결과 20분내에 크롤링이 끝나 놀라운 결과를 얻을 수 있어 만족스러웠습니다.