참고 - DDD-START! (지앤선 - 최범균 지음) - 개발자가 반드시 정복해야 할 객체 지향과 디자인패턴 (인투북스 - 최범균 지음) DIP 정의 고수준 모듈은 저수준 모듈의 구현에 의존하면 안된다. 저수준 모듈이 고수준 모듈에서 정의한 추상타입에 의존해야 한다. 변하기 쉬운것에 의존하지 마라. 먼저 아래 코드를 보자. public class CalculateDiscountService { private DroolsRuleDiscounter droolsRuleDiscounter; public CalculateDiscountService() { droolsRuleDiscounter = new DroolsRuleDiscounter(); } public Money calculateDiscountUsing..

참고 : 객체지향의 사실과 오해 - 조영호 지음, 위키북스 요즘 DDD (Domain Driven Design) 에 대해 공부하기 시작했습니다. DDD에 대해 공부하고 정리를 하는 것이 목표 였으나... 현재의 상태는 비슷한 내용을 어디서 봤던 것 같은데...? 아 이 내용은 전에 공부했었던 책 그 부분을 다시 한번 보면 좋겠다. 이러한 생각이 들고 있습니다. DDD 공부를 위해 책을 폈지만 DDD 에 대하여 배운다기 보다는 전에 다른 책을 통해 공부 했었던 내용이 조금씩 떠오르고 있습니다.(아직 책의 앞부분을 읽고 있어서 이런 일을 겪고 있는 것 일수도 있습니다.) 머릿속에 흩어져 있던 개념들이 이제 와서야 조금씩 정리가 되고 있는 느낌을 받고 있습니다. 그래서 DDD 에 대한 내용을 정리하기에 앞서 ..

Kafka 카프카는 메시지라고 불리는 단위를 다룹니다. 보내는 측(프로듀서)에서는 토픽이라는 메시지 저장소에 메시지를 저장하고, 메시지를 가져가는 측(컨슈머)은 원하는 토픽에서 메시지를 가져가기만 하면 됩니다. 중앙에 메시징 시스템 서버를 두고 메시지를 보내고(publish) 받는(subscribe) 형태의 통신을 펍/섭 모델이라고 하고 카프카는 펍/섭 모델을 기반으로 만들어진 메세징 시스템 입니다. 그래서 카프카에 대해 알기 위해선 펍/섭 모델, 메시징 시스템에 대해 알아야 한다고 생각합니다. 그래서 이번 글에서는 카프카에 대한 설명 위주가 아닌 메시징 시스템을 도입하면 좋은점에 대해 설명하고 다른 메시징 시스템에 비해 카프카를 왜 사용해야 하는지에 대해서 간단하게 설명하겠습니다. 메시지 발행/구독 시..

좋은 테스트란 ? 일반적으로 좋은 테스트란? 테스트에 관한 기준은 상황 및 사람에 따라 다르겠지만 일반적으로 테스트 관련 책이나 문서들을 보면 아래와 같은 특성을 가진 테스트가 좋은 테스트라고 말합니다. 검사하고 싶은게 무엇인지 알기 쉬워야 한다. 테스트를 믿을 수 있어야 한다. 빨리 결과를 알 수 있어야 한다. 독립적으로 실행이 가능해야 한다. 특정 환경에 종속되지 않아야 한다. 테스트 코드를 짤 때, 특정 언어나 기술을 사용했다고 좋은 테스트야! 라고 말하지는 않습니다. 그 보다는 위와 같은 특성을 얼마나 가지고 있는지의 여부가 좋은 테스트인지 아닌지를 판가름하는 것 같습니다. (물론 위에 더 많은 특성들이 존재하지만 일부만 적었습니다. 관련 내용이 궁금하시면 아래 참고자료를 봐주세요) 1. 테스트의..

테스트에 관한 시리즈 글을 작성해보려 합니다. 이 글은 본격적으로 글을 작성하기 전에 테스트 코드를 작성하며 제가 느꼈던 것들을 짧게나마 공유해보려고 작성하기 시작한 글입니다. 테스트에 대해 알기 전 테스트에 관한 책들을 보기 전, 테스트에 대해 더 알고 싶다는 마음을 가지기 전에 테스트 대한 생각은 아래와 같았습니다. 테스트 코드는 작성한 코드가 잘 돌아가는지 확인하기 위한 목적의 코드 이후에 수정될 될 일이 없는 코드에 대해선 굳이 테스트 코드가 필요 없다 테스트 코드를 작성하면 개발 시간이 오래 걸린다 현재의 첫 회사에 입사하기 전에 개발 공부를 할 때 저는 코딩을 할때 테스트 코드를 작성하지 않고 코딩을 했었습니다. 필요한 기능을 구현할 때 System.out.println() 을 이용하여 값을 ..

Tomcat 실행시 스프링 내부 동작과정에 대해 설명해볼게요 Tomcat 실행했을 때 일어나는 동작 톰캣 실행전에 web.xml에 으로 전역 파라미터를 설정해요. 파라미터 이름은 contextConfigLocation이고 어떤 객체들을 미리 만들어 놓을지가 작성된 설정파일의 경로를 적어놔요. 톰캣이 실행되면 클래스(리스너)의 이름을 같은 web.xml에 작성해요. 톰캣을 실행하면 가 등록되어 있는 ContextLoaderListener 객체를 호출하는데 이 객체는 내부적으로 부모객체를 실행해요. 부모객체는 ContextLoaderListener이며, 이 객체에서 Root ApplicationContext를 생성하고 웹과 관련이 없는 객체를 저장해요.(ex: dao) Root ApplicationConte..

Thymeleaf LocalDateTime 사용법에 대해서 알아볼게요. Thymeleaf에서 LocalDateTime 을 처음 쓸때... 여기서 스트레스 받는 분이 은근 많더라구요. POST 방식에서 사용하는 법. 우선 사용중인 Domain 클래스는 이런식으로 되어있어요. 아래는 생략~ html 파일에서 날짜를 선택할 거에요. 그래서 input 태그를 아래와 같이 만들어줬어요. {% codeblock %} {% endcodeblock %} Contorller 에서는 아래와 같이 만들어 줬어요. 전체 코드는 아니고 필요한 부분만 찰칵! {% codeblock %} @PostMapping("/product_detail/register") public String registerProduct(@ModelAtt..

이번 포스팅은 spring mvc 에 대해 써보려해요! 스프링 MVC가 요청을 어떻게 처리하고 돌려주는지에 대해 알아보기로 해요! 스프링 MVC 요청 처리 과정 스프링은 위에 그림과 같은 구조로 요청을 처리해요. 요청을 디스패처 서블릿, 핸들러 매핑, 컨트롤러, 뷰 리졸버 등으로 이동시키고 응답하게 되는 구조예요! 우선 요청(1) 이 브라우저에서 떠나면서 사용자가 요구하는 내용을 전달하게 돼요. 적어도 URL을 포함하고 있으며 폼에서 입력된 값들처럼 더 많은 추가 정보들이 전달 될 수도 있어요. 요청의 첫번째 도착지는 스프링의 DispatcherServlet 이에요. 대부분의 자바 웹 프레임워크와 마찬가지로 스프링 MVC 역시 많은 요청들을 하나의 프런트 컨트롤러 서블릿에서 처리해요. 단일 프론트 컨트롤..

JPA는 @Transactional 로 묶인 곳에서 Entity 를 관리해요. @Transactional 은 스프링에서 트랜잭션을 관리하는 방법 중 하나인데, 프록시를 이용해서 타겟 오브젝트를 감싸고 트랜잭션 시작/끝 부가기능을 앞뒤에서 제공해요. 때문에 외부에서 접근해야 프록시가 적용되기 때문에 @Transactional 이 적용된 자기 자신(this)의 다른 메소드를 호출하려면 그냥 하면 안되고 부가적인 작업이 필요해요. JPA는 데이터베이스로의 무분별한 접근을 막기위해 영속성 컨텍스트에서 엔티티를 관리해요. 엔티티를 관리할 때 Lazy 란 개념이 있어요. 어떤 엔티티의 모든 필드가 필요한것이 아닐 경우가 있어요. A가 B를 필드로 가지고 있는데, B엔티티의 모든 필드가 당장 필요한게 아니라 A엔티티..

서블릿 동작 과정에 대해 간단하게 알아봐요. 클라이언트가 웹 브라우저에 URL 입력을 하면 해당하는 HTTP Request를 해당하는 서버의 Servlet Container 에 보내요. Servlet Container 는 요청, 응답 객체를 생성해요. 클라이언트가 요청한 URL을 web.xml을 참조해서 분석하고 어느 서블릿에 대한 요청인지 찾아요. 서블릿이 처음 요청된 경우에는 서블릿 클래스를 메모리에서 로딩하여 객체를 생성해요. 생성된 객체는 메모리에 계속 존재하므로 이후에 동일한 요청이 왔을 때는 기존의 객체를 사용해요. init() : 객체가 생성되면서 init()이 최초에 한번 호출돼요 service() : 요청 메소드(GET,POST)에 따라 실행돼요. 여러 클라이언트가 동시에 요청을 하더라도..

JPQL @Query 메소드에서 2개 이상의 프로젝션을 리턴할 때 어떤식으로 받아야 하는지 알아볼게요!! 스프링 프로젝트를 진행중에 생겼던 이슈에 대해 적어볼까 해요! 이번 이슈는 JPQL 에 관한 이슈에요. SQL 문을 짜는 것도 고역이었는데 그 이후에도 이슈가 생겨서 정말 뚝배기 깨질뻔했네요. 먼저 대략... 2시간에 걸쳐서 겨우겨우 SQL문을 완성했어요. 이번 포스팅에 필요한 부분만 올리자면! select me.*, me.name , count(*) from member ~ group by ~ ; 많이 생략했지만 이것만 있어도 돼요! 겨우겨우 구현한 SQL 문! Mysql Workbench 에서 실행하면 결과 잘 나옵니다. 그런데! 프로젝션이 하나인 경우만 써봤는데... 이번 SQL문은 프로젝션이 ..

Observer Pattern 옵저버 패턴이란? 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다 의존성을 정의해요. 일대다 관계는 주제(Subject) 와 옵저버(Observer) 에 의해 정의돼요. 옵저버는 주제에 의존하고 주제의 상태가 바뀌면 옵저버한테 연락이 가고 연락방법에 따라 옵저버에 있는 값이 새로운 값으로 갱신될 수도 있어요. 클래스 다이어그램 Subject 인터페이스는 객체에서 옵저버로 등록하거나 옵저버 목록에서 탈퇴하고 싶을 때는 이 인터페이스에 있는 메소드를 사용하죠 옵저버가 될 가능성이 있는 객체에서는 반드시 Observer 인터페이스를 구현해야 해요. 이 인터페이스에는 주제의 상태가 바뀌었을 때 호출되는 update(..