분류 전체보기

스프링 시큐리티 - Spring Boot 기반으로 개발하는 Spring Security - 인프런 | 강의 초급에서 중.고급에 이르기까지 스프링 시큐리티의 기본 개념부터 API 사용법과 내부 아키텍처를 학습하게 되고 이를 바탕으로 실전 프로젝트를 완성해 나감으로써 스프링 시큐리티의 인증과 www.inflearn.com 💭 Spring Security 스프링 기반의 앱에서 보안(인증, 권한, 인가)등을 담당하기 위해 만들어진 하위 프레임워크이다. Spring Security는 보안을 담당하는 프레임워크이다. 그래서 스프링 앱과의 의존성을 분리시키기 위해 기본적으로 서블릿 필터기반으로 동작하게끔 만들어져있다. 즉 스프링을 사용하지 않더라도 서블릿을 사용하고 있다면 따로 적용이 가능하다. Spring Secu..

# 레퍼런스 https://msolo021015.medium.com/jpa-persistence-context-deep-dive-2f36f9bd6214 JPA Persistence Context Deep Dive 최근 저는 새로운 프로젝트를 진행하면서, JPA를 도입하였습니다. msolo021015.medium.com #logging.level.org.hibernate.event.internal.AbstractFlushingEventListener=DEBUG JPA를 쓴다면 OpenEntityManagerInViewFilter를 고려해야한다 JPA LazyLoading은 관리하는 세션 사이클에 포함되어 있을 때만가능하다. 트랜잭션 범위를 벗어나면 (View에 전달된 이후에는) 쿼리 호출이 불가능하다. 그..

# 레퍼런스 어플리케이션 아키텍처와 객치지향 우아한 객체지향, 의존성을 이용해 설계 진화시키기 마이크로서비스 개발을 위한 DDD 실습 정명주 - DDD-Lite@Spring, 전략적 DDD 우아한 CRUD 배달의민족 CEO에게 뽑고 싶은 개발자를 물어보았다. 마켓커리 - DDD로의 선회 #1 마켓커리 - DDD로의 선회 #2, 이벤트 스토밍 마켓커리 - DDD와 MSA 기반으로 좋은 서비스 개발하는방법 우아한 모노리스 - MSA가 무조건 좋은 방법일까? 도메인 주도 설계 핵심 - 반 버논 (책) Domain Driven Design Quickly - 에릭에반스 DDD 요약집 -- 세미나 정리 조영호, 이규원(TDD) 리펙토링 https://github.com/msbaek/expense intellij14..

간단한 CRUD는 JPA 메서드로 충분히 대체 가능했다. 하지만 SQL문은 비즈니스의 구조에 따라 조건이 복잡할수도 있고, 성능 개선이 필요할 수 있다. 이를 위해서 JPA 영속성 컨텍스트에 모든 데이터를 가져오는건 사실상 불가능하다. 이를 위해 JPA에서는 JPQL이라는 Entity용 SQL을 제공한다. 📌 JPQL 표준 문법 SQL 표준 문법과 매우 유사하다. ANSI (American National Standards Institute) 표준 SQL의 기능은 전부 지원한다. 단 유의할 점은 Entity를 대상으로 하는 쿼리문이다. 당연히 실제 DB Query는 다르게 찍힌다. 즉, 추상화된 SQL을 사용하는거라 특정 데이터베이스 SQL에 의존하지 않는다. 📌 JPQL 생성 - JPA Criteria..

https://www.youtube.com/watch?v=rYj8PLIE6-k&list=PL42XJKPNDepZVLkCM4yEKmU4LHyXjzChy&index=8 테이블은 정규화를 하여 최소한의 데이터를 높은 성능으로 조회, 변경한다. Entity는 식별자와 생명주기를 가지며, 연관관계는 참조 값으로 만든다. 테이블은 외래키 하나로 양방향 참조가 가능하지만 Entity는 불가능하다. 각각 참조를 가지고 있어야한다. 테이블의 외래키를 가지고 있는 주인은 1개지만 Entity는 2개이다. 그게 아니면 단방향으로 하거나 📑 보통은 단방향으로 충분하다. 맞는 말이다. 중간에 Cascade로 영속성 상태 전이가 가능하다. 물론 반대방향 (1:N)도 마찬가지 하지만 위의 코드는 기대한대로 동작하지 않는다. 외래키..

https://www.youtube.com/watch?v=TdyOH1xZpT8 📑 복잡성 기술은 빠르게 발전하는데 개발자는 왜 계속 고통받는가 왜 우리 프로젝트는 가면 갈수록 더 힘든가 왜 유지 보수 비용은 끊임없이 증가하는가 진짜 중요한게 대체 무엇인가 빠르고 간단하게 구축하다보니, 서비스가 커지면 주기적으로 프로젝트를 엎고 다시 시작해야한다. 물론 개선을 포기하고, 현재 상태를 유지하는 방법도 있다. 하지만 변화에 적응하지 못하면 비즈니스는 도태된다. 📑 DDD (Domain Driven Architecture) 큰 프로젝트의 핵심을 뽑아내서 세부 도메인으로 분리하자. 핵심 도메인: 비즈니스의 핵심이 되고, 가장 어렵고 복잡한 곳(쇼핑몰 ➡ 결제, 쇼핑 ) 지원 도메인: 핵심 도메인을 도와주는 기능...

https://www.youtube.com/watch?v=SrQeIz3gXZg&t=162s 💭 MSA가 무조건 좋을까? 당연히 아니다. 원래 하나였던 것을 여러개로 쪼갠 것이다. 즉 원래 혼자서 해결했던 문제를, 여러 부분에서 나누어서 값을 전달해야한다. 기능이 복잡해지고 코드와 로직이 분산되어있다. ➡ 새로운 비즈니스 요구사항을 빠르게 반영하기 어렵다. 이게 한 개발자, 한 팀안에서 일어나는 일이면 그나마 괜찮다. 귀찮더라도 하면 되니까. 하지만 협업을 하는 서비스가 다른 팀의 서비스라면? 대규모 서비스라서 팀 구성이 복잡하다면? 실제 서비스는 시간적 여유가 넉넉하지 않다. 일단 동작하게 만들기 위해선, 개발팀이 어디를 집중해야할까? ➡ MSA의 구조는 기술부채를 가속화 시킨다. 전체를 손 보기 너무 ..

https://www.youtube.com/watch?v=dJ5C4qRqAgA 💭 설계란 무엇인가요? 코드를 어떻게 배치할 것인가. 어떤 패키지에 어떤 객체를 넣을 것인가. 왜 그런걸 고민할까? 결국 설계를 하는 본질은 변경을 관리하는 것에 있다. 변경의 전파는 의존성을 의미한다. 같이 변경되는 코드를 함께 넣어라 의존성을 바탕으로 설계하라. 📑 의존성의 종류 연관관계 Association (영구적) 의존관계 Dependency (일시적) 상속을 이용한 확장 Inheritance ( 상속, 자식 ) 인터페이스를 통한 확장 Realization ( 실체화 ) 📑 좋은 의존성1 - 꼭 필요한게 아니라면 의존성을 없애버려라 📑 좋은 의존성2 - 양방향 의존성을 피하라 양방향으로 의존성을 가진다는 것 = 항상 ..

어플리케이션 계층이 인프라를 의존하는 경우 구현을 교체하기 어렵다 응용 서비스나 도메인 로직 테스트가 어렵다. (인프라 없이 테스트하기 까다롭다. 결과가 다르게 나올 수 있다.) 왜 이런 문제가 발생할까? 다른 레벨(고수준, 저수준)이 섞여있기 때문이다. 영화 예매하기 (고수준) JPA로 영속성 객체 보관하기 (저수준) DB에 SQL 날리기(저저수준) 💭 해결책 DIP. 고수준의 입장에서 저수준을 추상화하라. 그런데 추상화할 때 많이 실수하는 부분이 있다. '추상화'를 하라고 하니 단순히 인터페이스를 올리고, High-Class의 이름을 뽑아서 사용하는 구조 사실 이는 제일 처음 봤던 구조와 다른게 없다. 상위 모듈이 하위 모듈을 의존하고 있으니까 올바른 DIP는 객체 본인 입장에서 생각하는 것이다. '..

https://www.youtube.com/watch?v=26S4VFUWlJM 마틴 파울러가 이렇게. Transaction Script (절차지향) Domain Model (객체지향) * Table Module 패턴 (테이블 = Entity 완전 동일하게 사용)은 자바쪽에선 거의 사용안함. 💭 도메인 레이어가 전체 아키텍처를 구성한다. 도메인을 어떻게 짜느냐에 따라 아키텍처 구성이 달라진다. 💭 요구사항 살펴보기 온라인 영화 예매 시스템을 Transcation Script와 Domain Model로 나누어서 구현해보자. 비즈니스 기능 : 영화를 예매한다. 도메인 개념 : 시스템을 구현하는 개념들 [영화] - 메타데이터. 영화에 대한 정보 [상영] - 예매할 주체 [할인] - 소비자를 특정한 시간대로 유도..

DRY Dont Repeat Yourself OCP Solid 전체가 OCP를 위한 하부원칙이라고도 볼 수 있다. 소프트웨어의 구성요소는 확장은 가능하지만 수정은 불가능해야한다. 기능을 추가하거나 현재 개체의 변경은 가능해야한다. 단 어떤 개체를 수정할 때, 다른 모듈이 영향받지 않도록 하라. (인터페이스를 수정하려고 하지마라) 아키텍처를 이야기할 때에는, 관심사의 분리(Separation of Concerns) 라는 용어를 자주 듣게 된다. 결국 아키텍처를 사용하는 이유는 서로 다르고 관련이 없는 책임(Responsibility)를 분리하는 것이다. 💭 컴퓨터는 이벤트를 처리하는 도구이다. 사용자의 이벤트를 안전하게 처리하기 위해서 트랜잭션 단위로 구분 짓게 된다. 즉 우리가 만드는 어플리케이션은 컴퓨..

JPA에서는 2가지 데이터 타입을 제공한다. @Entity 는 데이터가 변해도 식별자로 계속 추적이 가능하다. 값이 변경되면 식별자로 인식 가능하다. 기본 값 타입은 @Entity 와 생명주기를 공유하며, String, Integer, int 등을 의미한다. 단, 값 타입에 대한 식별자는 따로 존재하지 않으므로 JPA의 변경추적이 불가능하다. 이게 무슨말이냐면, 외부에 값타입을 변경할 수 있는 참조가 있다면 Side-Effect가 발생할 위험이 있다는 말. 뭐 사실 자바에서 Primitive Type (int, long)은 참조값 공유가 불가능해서 별 상관이 없다. Integer나 String은 래퍼타입은 참조값은 공유가 가능하지만, 변경이 불가능하게 막혀있다. 그래서 이걸 설명하는 이유가 뭐죠? 당연한..