Architecture ‐ Monolithic Architecture - dnwls16071/Backend_Study_TIL GitHub Wiki

📚 Monolithic Architecture

  • 소프트웨어 개발에 대한 기존의 접근 방식
  • 단일 단위로 완전한 애플리케이션 개발(대부분의 레거시 애플리케이션)
  • 단일 코드베이스 개발
    • UI + Business + Data : 동일한 코드베이스 기조
    • 단일 패키지(jar/war) 파일로 대규모의 프로젝트를 배포
  • 빠르게 시작, 디버깅 쉬움
  • 관리하기 어려움, 새로운 기능 구현하기 어려움
  • 장점
    • 개발이 간편 : 기존 개발팀은 모놀리식 애플리케이션을 개발할 수 있는 올바른 지식과 역량을 갖추고 있다.
    • 디버깅 및 테스트가 더 간편 : 디버깅 및 테스트가 간편하고 단일 코드 기반이기 때문에 E2E 테스트를 훨씬 더 빠르게 실행 가능하다.
    • 배포 간편 : 여러 배포를 처리할 필요 없이 파일이나 디렉터리 하나만 배포하는 형태, 단일 jar/war만 배포되므로 배포가 더 용이하다.
  • 단점
    • 시간이 지남에 따라 복잡해짐 : 이해하기 어려움
    • 새로운 변경을 하는 것이 어려움 : 매우 긴밀한 결합으로 인해 사이드 이펙트 발생 위험 높음
    • 확장하기 어려움 : 구성 요소를 전체 확장해야하므로
    • 새로운 기술 도입에 대한 장벽 : 모놀리스에서 발견되는 상호 연결된 종속성 문제

📚 Monolithic Architecture 적용

  • DRY - Don't Repeat Yourself
    • 모든 지식은 시스템 내에서 단일하고 모호하지 않으며 확고한 표현을 갖도록
    • 시스템 기능의 동작을 단일 코드로 유지하려고 노력
    • 중복된 코드나 디자인 항목이 없도록
  • KISS - Keep It Simple, Stupid
    • 코드나 시스템은 단순하게
    • 불필요한 복잡성은 피하도록
    • 간단한 코드는 유지 관리가 더 쉽고 이해하기도 더 쉽다.
  • YAGNI - You aren't gonna need it
    • 가능하면 작동할 수 있는 가장 간단한 것을 하라.
    • 실제로 필요하지 않은 기능을 만들지 말라.

📚 Layered Architecture

  • N 계층 아키텍처 스타일 또는 다중 계층 아키텍처 스타일
  • 애플리케이션 내에서 특정 역할을 수행하는 각 계층을 수평적 논리적 계층으로 구성
  • 구성 요소는 상호 연결되나 서로 의존하지 않음
  • 관심사 분리를 위한 코드 작성
  • 계층을 수정할 수 있고 변경 사항이 다른 계층에 영향을 미치지 않도록 계층을 격리
    • Presentation Layer : 웹 앱과 같은 소프트웨어 시스템과의 사용자 상호작용을 담당
    • Application/Business Layer : Business 구현을 위한 기능적 요구사항 처리
    • Database Layer : SQL과 같은 데이터 처리를 담당

📚 Clean Architecture

image

  • 프로젝트 요구사항을 기반으로 하는 정책과 비즈니스 로직에 집중
  • 내부 계층에는 비즈니스 규칙이 포함되어 있으며 타사 라이브러리에 종속되지 않음
  • 외부 기관에 대한 독립성
    • 비즈니스 규칙이 외부 세계에 대해 전혀 알지 못한다.
  • 데이터베이스 및 프레임워크에 독립적
    • SW는 ORM이나 DB에 의존하지 않음
    • 쉽게 변경할 수 있음
  • UI 독립성
    • UI는 다른 시스템과 비즈니스 규칙을 변경하지 않고도 쉽게 변경 가능
  • 테스트 가능
    • UI, 데이터베이스, MockUp 서버 등을 고려하지 않고 비즈니스 규칙에 대한 테스트 가능
  • 장점
    • 쉬운 개발 / 디버깅 / 배포
    • 느슨하게 결합된 독립 계층
    • 유연한 논리적 계층
    • 테스트 용이하고 독립적이며 다른 라이브러리로 변경 가능
  • 단점
    • 확장성 문제