우테코 생존기

검증 로직의 위치에 대해 리뷰어 핀과 논의 하면서 VO를 도입하게 되었다. 이전에는 하나의 입력에서 검증 해야 하는 것들을 하나의 클래스에서 처리 하는 것이 의미 있다고 생각했다. 하지만 이렇게 되면, 입력을 변환하는 과정(예를 들어 ,로 String을 분리)이 있을

생성 후 상태를 바꿀 수 없는 객체즉, 힙 영역에서 객체가 가리키고 있는 데이터 자체의 변화가 불가능한 것ex) Money의 필드 int형 money는 한 번 값을 할당하면 변경할 수 없다.가장 많이 사용하는 불변 객체는 바로 String입니다.이런 것이 가능한데, S

검증 로직의 위치는 어디?도메인이 불완전한 상태로 생성 및 사용되지 않도록 검중 로직 위치를 정해야한다.⇒ 도메인 검증은 도메인 객체가 직접!⇒ 대부분 생성자에서 생성이 되므로 주 생성자에 검증 로직이 있는 것이 좋을 것 같다.비지니스 로직은 도메인에!일급 컬렉션 보

1단계 미션을 진행하며, 로또를 만드는 역할을 하는 LottoFactory 라는 클래스에서 로또가 생성되는지 확인하는 테스트 1개를 진행했었다.그런데 추후에 다른 테스트를 진행할 수 있을 것 같아서 LottoFactory 를 전역변수로 선언했었다.여기에 루피가 책의 내

지금까지 자동차경주, 로또 미션을 진행했는데 이번 블랙잭 미션은 도메인 이해도가 가장 낮은 미션이였다.한 번도 해본 적이 없는 게임이지만 미션을 보고 이렇게 게임이 돌아가는 구나~ 라고 생각해서 구현을 했다.그랬더니 아래와 같은 리뷰를 받았다.실행 결과의 예시가 아래와

체스 미션 중, source에서 target까지 정해진 방향으로 계속 한 칸씩 움직이면서 장애물을 확인하는 로직이 있었다.file값과 rank값을 더하고 빼서 정해진 방향으로 한 칸씩 이동하는데 이동 로직이 정해진 방향으로 board 내부의 값까지 이동하기 때문에 bo

안녕하세요. 이번 포스팅은 상태가 Optional할 때 생길 수 있는 문제점을 알아보고 대처 방안 중 하나인 빌더 패턴에 대해서 알아보겠습니다.빌더 패턴이란 생성 패턴 중에 하나로, 생성 패턴은 인스턴스를 만드는 절차를 추상화하는 패턴입니다.객체를 생성할 때 모든 상태

하나의 flow로 처리해야하는 로직으로 더 이상 쪼개질 수 없는 최소의 연산을 의미합니다.transaction은 ACID의 특성을 가집니다.트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 특성트랜잭션이 실행을 성공적으로 완료하면 언제나 일관

격리 수준이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터들을 볼 수 있게 허용할지 말지를 결정하는 것이다.그렇다면 격리 수준에는 어떤 것이 있을까?어떤 트랜잭션의 변경 내용이 COMMIT되든 ROLLBACK 되든 상관

장바구니 미션을 하다가 아래와 같은 리뷰를 받았다.유니크 인덱스를 설정하면 조회시 성능상에 이점이 있다는 것을 처음 알게 되었는데 요리조리 검색해봐도 잘 나오지 않았다.RealMySQL이라는 책을 읽으면서 왜 그런지 알게 되었고 포스팅을 하게 되었다.MySQL에서는 컬

개발을 하며 저장소인 github를 자주 사용하게 됩니다.하지만 코드 중 Secret Key와 같은 공유되어서는 안되는 정보도 있습니다.이런 정보들은 어떻게 관리해야할까요?Spring에서는 resource 패키지에서 appication.propertis 혹은 appli

인수테스트(Acceptance Test)란 사용자 시나리오 테스트로 흔히 블랙박스 테스트라고 불린다.블랙박스 테스트는 소프트웨어 내부 코드에 관심을 가지지 않는 테스트로, 개발자가 아닌 사람들도 보고 이해할 수 있어야하는 테스트다.\[Spring 지하철 노선도 - 3단

팀 프로젝트에서 게시물 추천 기능을 개발하게 되었는데요.개발 과정에 대해서 써보려고 합니다 :)추천은 게시물에 대한 추천이지만 누가 추천했는지도 알아야합니다.따라서 추천 테이블에 게시물에 대한 식별자와 유저에 대한 식별자가 필요하다고 판단했습니다.Like와 Articl

logback을 이용하여 운영 환경 및 콘솔에서 로그를 찍어봅시다!공식 팀의 깃허브에서 자세한 코드를 확인하실 수 있습니다.클라우드를 사용하는 운영 환경에선 application의 상태를 알지 못합니다.그렇다면 클라이언트가 알 수 없는 에러가 발생한 경우를 대비하여 로

팀 프로젝트에서 github OAuth를 이용한 로그인을 구현한 과정을 공유합니다.자세한 코드는 공식 팀의 깃허브에서 확인 하실 수 있습니다.내 프로필을 선택하고 setting을 누릅니다.setting 내의 Developer settings -> OAuth Apps -

github login을 구현하며 외부 api가 포함된 비지니스 로직을 테스트하기 위한 시도와 실패에 대한 포스팅입니다!자세한 코드는 공식 팀의 깃허브에서 확인 하실 수 있습니다.현재 Github OAuth를 이용하여 위와 같은 순서의 로직으로 로그인 API를 구현하였

공식팀에서 Flyway를 도입하게 된 이유와 Flyway의 작동방식, Flyway를 사용하며 겪은 트러블 슈팅을 공유합니다! Flyway란? flyway는 데이터베이스의 DDL의 이력을 쌓아서 DDL이 어떻게 변화되었는지 관리하는 툴입니다. 이를 통해서 데이터베이스의