내부 인증 시스템 개발하기

프로젝트는 MSA 구조여서 여러 프로젝트들이 존재한다. DB 도 도메인 별로 분리되어 있다.

 

이러한 상황에서 여러 프로젝트에서 로그인 기능이 필요한데, 어떤 프로젝트는 public open 이지만 어떤 프로젝트는 내부 시스템용이다. 

 

로그인 기능이 반복적으로 나오고 따라서 이러한 관심사를 처리할 별도의 프로젝트가 필요하다.

 

작업 내용 : 작업기간이 길지 않고 내부 시스템만 사용할 시스템이다.

개발을 빠르게 하고 MSA 에서의 확장성을 위해 openapi, jwt 를 선택했다.

 

이렇게 했을 때 장점은 스프링 진영에서 지원하는 라이브러리로 설정 몇개만 해주면 작업이 끝난다는 점이다.

spring-boot-starter-oauth2-resource-server

 

단점은 openapi 프로토콜과 동일하게 해야 하고 커스터마이징이 다소 힘들다.

 

---

TDD 로 인증 서버를 구현하였다. MSA 로 구현된 서버 자체를 하나의 컴포넌트라고 생각하니까 테스팅이 쉬운 구조이고 TDD 의 장점을 가져갈 수 있었다.

 

기존의 A 서버에서 사용하던 로그인 및 리소스 API 를 제공하면 되는 것이므로, 인증 서버의 통합 테스트 코드와 외부 서비스의 코드가 다르지 않다. 따라서 개발 시 A 서버의 코드 변경을 고려하지 않아도, 인증 서버를 테스트 코드와 함께 개발한 후 integration 을 용이하게 할 수 있다.

 

---

TDD 와 MSA 의 공통점?

 

두 개의 개념에 대해 공부할 필요를 느낀다.

 

둘 다 주장하는 것이 객체지향에서 주장하는 개념인 loosely coupled and highly cohesive system 이다.

<MSA 에 관한 글>

https://helloworld.kurly.com/blog/ddd-msa-service-development/

DDD와 MSA 기반으로 좋은 서비스 개발하기

<TDD 에 관한 글>

https://arxiv.org/ftp/arxiv/papers/1711/1711.05082.pdf

 

 

MSA 는 DDD 와 관련이 있고 구조의 장점으로 위 개념을 가진다.

 

TDD 는 개발 방법론을 지켰을 때 결과물이 위 개념을 가지게 된다.

 

따라서 도메인을 (예를 들면 인증에 대한 것, 유저 리소스에 대한 것) 분리하고 그 서버를 TDD 로 개발하면 loosely coupled and highly cohesive system 이 만들어지지 않을까? 

 

테스트 코드를 작성함으로써 구현에 대한 것이 explicit 해 진다는 장점도 있다. (API 통합 테스트를 짜면 심지어 외부에서 쓸 때 테스트 코드를 보고 쓸 수도 있다.)

 

테스트 하기 쉬운 코드는 좋은 아키텍처일 확률이 올라간다는 이야기가 있는데 ... 테스트를 먼저 짜고 하면 구조가 좋아진다. (근데 그러면 시간이 오래 걸린다)

 

(이번 주말에 공부해 봐야겠다.)

 

 

 

---

(주말이 되었다.)

 

도메인 주도 설계 첫걸음 이라는 책을 봤다.

 

Bounded context & 하위 도메인

비즈니스 도메인 = 여러 하위 도메인

하위 도메인 = 상호 관련된 유스케이스 집합, 비즈니스가 담담하는 요구사항의 정의

바운디드 컨텍스트 = 비즈니스 도메인의 모델의 경계, 개발자가 설계한다.

시스템을 바운디드 컨텍스트로 분리 → 장점 = 유비쿼터스 언어의 범위가 작고 관리하기 쉬워진다. 단점 = 너무 잘게 나누면 응집성이 낮아진다.

각각의 바운디드 컨텍스트는 개별 프로젝트로 구현돼야 한다. 구현, 진화, 버전 관리를 독립적으로 한다.

바운디드 컨텍스트는 물리적 경계 (프로젝트로 나뉨) 이고 하위 도메인은 논리적 경계(네임스페이스로 나뉨)이다.

마이크로 서비스란 자신의 퍼블릭 인터페이스에 의해 정의되는 서비스이다.

 

즉, 바운디드 컨텍스트가 일반적으로 MSA 라고 오해하는 개념이고, MSA 는 물리적인 시스템 아키텍처, DDD 는 이를 구현하는 개념에 대한 거다.