😒일상/멘토링

보호되어 있는 글입니다.

# 레퍼런스 어플리케이션 아키텍처와 객치지향 우아한 객체지향, 의존성을 이용해 설계 진화시키기 마이크로서비스 개발을 위한 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..

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)를 분리하는 것이다. 💭 컴퓨터는 이벤트를 처리하는 도구이다. 사용자의 이벤트를 안전하게 처리하기 위해서 트랜잭션 단위로 구분 짓게 된다. 즉 우리가 만드는 어플리케이션은 컴퓨..

보호되어 있는 글입니다.

보호되어 있는 글입니다.