Clean Architecture 스터디

[SAgiKPJH]

Clean architecture 스터디 내용 정리

[SAgiKPJH]

Clean architecture의 유래

CleanArchitecture

• 관심사 분리
• Layer
• 계층구조

Business / Tech 분리

• 1차 분리
  • Business와 Tech 관점으로 분리
• 2차 분리
  • 비즈니스 흐름과 용어 분리
• 비즈니스 기준으로 나누어야 한다.

찾을 수 있는 코드

• 쉽게 찾을 수 있는가가 중요하다.
• 관심사를 분리하여 쉽게 원하는 것을 찾을 수 있다.
• 프로젝트 내부에서 쉽게 원하는 바를 찾을 수 있어야 한다.
  • 비즈니스 기준으로 나누면 -> 찾을 수 있다.
  • 쉽게 찾을 수 있다 -> 코드 읽는 시간이 준다 -> 코드 읽기 편하다
• CleanArchitecture 장단점
  • 장점 : 분리/유지보수/Test
  • 단점 : 모르는 사람은 어렵다/리소스 많아진다

끝점 찾기

• 워크 플로우의 끝나는 지점을 쉽게 찾을 수 있어야 한다.

근본적인 것을 보는 힘

• 어떤 개념이든 근본적인 것을 생각하자.
• 어떤 개념의 유래와 배경에 대해서 알아보려고 하자.

JJU 이론

• Tech를 쪼개어 기본 언어(C# or Python) 또는 Package를 포함하는 레이어 (Language Layer)
• 도메인 레이어를 활용하여 구현된 Adapter Layer로 구성하면 어떨까 생각해봤습니다.
• 이러한 도메인 기술은 개발을 위한 기초적인 언어로, string, int 와 같은 개념이 포함됩니다.
• 그리고 이러한 도메인 기술을 어떻게 활용하느냐에 따라 Entity의 형태가 달라집니다.
  • 예) C#의 Enity, Python의 Entity의 구현 방식은 다릅니다.
  • 예) Package에 따라서도 구현 방식이 달라집니다.
• 따라서 다음과 같이 도메인 기술로 분리해봤습니다.
• 즉, 고객은 비즈니스의 흐름과 용어로 나누었다면, 개발자는 기술의 흐름(Logic)과 용어(Language)로 구성해봤습니다.

[SAgiKPJH]

관심사의 분리와 레이어

자가 점검

• CleanArchitecture 자가 점검 방법
• 코드를 보고 Business 이해 가능해야 한다.
  • 솔루션 탐색기를 목차와 같이 사용할 것
• Code가 곧 Document
  • 코드 없이 구조설계 설명 가능해야 한다.

Visual Studio 중앙관리

• 상세 정보 (https://github.com/SagiK-Repository/Learn_CleanArchitecture/issues/6)
• 중앙 패키지 관리
  • 프로젝트의 Nuget Package Version을 솔루션에서 관리합니다.
  • nuget.config 및 Directory.Packages.props 파일 추가해서 관리합니다.
• 중앙 빌드 관리
  • 프로젝트의 Property를 솔루션에서 관리합니다.
  • Directory.Build.props추가하여 관리합니다.

관심사 나누기 - UseCase

• UseCase의 관심사를 어떻게 나누는가?
• 트랜잭션 단위로 나눕니다.
• Service : 고객에게 무언가를 제공

Root Entity (= Aggregate Root)

• Entity에 포함되어 있는 VO(Value Object)
• VO에 Entity가 포함되어 있는 경우가 드물게 있습니다. (https://github.com/SagiK-Repository/Learn_CleanArchitecture/issues/7)
• Root Entity
  • 트랜잭션 총괄자/관리자
  • 기존 Entity와는 다르게 외부와 소통하는 특성이 있습니다.
• Aggregate : 여러 Entity를 하나로 관장

폴더 구조

• 상관관계를 기반으로 폴더를 구성합니다.
• Domain Layer
  • Aggregate / Entity / VO
• Application Layer
  • UseCase 1
  • UseCase 2
  • UseCase 3

[개인적인 생각] 나누기가 먼저일까? 비교가 먼저일까?

(여기서 말하는 나누기는 사과 4개와 같이 1개씩 나누는 것 입니다.)
(여기서 말하는 비교는 작은 사과와 큰 사과와 같이 비교하는 것입니다.)

• 조금 문학적인 생각일 수 있지만, 나누기가 있기에 비교가 가능할까? 아니면 비교가 가능하기에 나누기가 가능할까? 무엇이 먼저일지 고민해봤습니다.
• 모든 기준은 상대적이기 때문에, 비교가 가능해지고 따라서 나누기가 가능해진다 추측해봤습니다.
• 그러다가도 상대적이기 때문에 구분할 수 있고, 나누기 및 비교가 가능하다고 생각이 듭니다.
• 나누는 것과 비교하는 것이 서로 관점이 다른지 생각해 보았습니다.
  • 나누는 것은 구분하기 위한 것이고, 비교 하는 것은 차이를 알기 위한 것입니다.
  • 차이는 곧 구분이기에, 나누는것과 비교하는 것은 같이 차이에 의한 특성 입니다.
• 나누는 것은 차이를 기반으로 무언가를 하는 것이고, 비교는 곧 차이라 생각합니다.
  • 결론적으로 비교가 더 근본적인 내용이라 생각이 들었습니다.
• 따라서 비교가 가능하기에 나눌 수 있다 생각이 듭니다.

[SAgiKPJH]

레이어 관계 Test

Test 피라미드

• End to end
  • 기본적으로 1개만 존재
• Unit
  • 컴파일러 단계의 Test
• 💥반드시 Service 1개 당 Test 1개 존재할 것
  • 여기서 말하는 Test는 Integration + unit
  • Service 내에 여러 개의 프로젝트가 있을 수 있지만, 그래도 Test는 한 개여야 합니다.

Test 검증

• 1차 : 컴파일러
  • 프로젝트 구성을 통한 관계 검증
• 2차 : Test Code
  • Runtime 검사를 통한 검증

Test 코드의 역할

• Test
• 메뉴얼 (사용 방법)

관계 검증 방법

1) 프로젝트 관계 검증 (컴파일러 검증)

• 프로젝트 참조 및 접근 제한자를 활용
  • dotnet에서 프로젝트 참조 관계를 구성
  • 접근 제한자 (public, internal) 활용해서 구성
• 장점 : 관계 검증에 Test 코드 불필요
• 단점 : 난이도가 높다

2) Test Code 통한 관계 검증 (Runtime 검증)

• 패키지를 통한 아키텍처 관계 Test 진행
• dotnet package
  • ArchUnit
  • NetArchTest.Rule

컴파일러 검증의 중요성과 관계를 고려한 코드 구성이 중요하다는 것을 깨달았습니다.

[SAgiKPJH]

환경 설정 검증 및 아키텍처 테스트

환경설정 검증

• appsetting.json 검증
  • Option Validation
• simple fake data generator for C#
  • Bogus : https://github.com/bchavez/Bogus

Architecture Test

• 아키텍처 테스트
  • NetArchTest.Rule : https://code-maze.com/csharp-architecture-tests-with-netarchtest-rules/

질문

• Architecture Test Project는 어디에 위치하는 것이 좋을까?
  • 메모리 테스트 이기 때문에(프로세스 테스트 : integral Test) Unit Test Project에 위치합니다.
• Test하지 않은 Class가 있으면 테스트 통과 못하게 하는 방법은?
  • CI/CD에서 Test Coverage가 일정 수준 이하로 떨어지면 CI 통과 못하도록 할 수 있다.