일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 애그리게이트
- 비동기
- 정처기 준비물
- BOUNDED CONTEXT
- react native 내부 구조
- js
- typeScript
- std::char_traits<unsigned char>
- nextjs사용이유
- nextjs 라우팅
- Aggregate
- nextjs route code
- 불변식
- 정처기 자격
- IAP
- 빌딩 블록
- DDD
- in app purchase
- react natvie
- HTML
- rniap
- 이벤트 시스템
- react native bridge
- 정보처리기사
- 이펙티브 타입스크립트
- 타입스크립트
- TS
- 속도개선
- nextJS
- rn
- Today
- Total
목록DDD (6)
nika-blog
🎯 도메인 모델과 코드의 관계📌 DDD의 핵심 원칙:"도메인 모델과 코드는 같은 의미를 가져야 한다."즉, 코드 자체가 도메인 모델을 반영해야 하며, 별도로 문서를 유지보수할 필요가 없어야 함.✅ 해결해야 할 두 가지 문제1️⃣ 요구사항에 적합한 모습으로 도메인을 어떻게 모델링할 것인가?2️⃣ 도메인을 반영한 코드를 어떻게 개발할 것인가?💡 코드가 문서 역할을 한다면?✔ 변경되는 문서를 따로 유지보수할 필요 없이,✔ 코드를 보면 도메인 모델을 이해할 수 있도록 설계하는 것이 핵심.🔨 모델 주도 설계의 빌딩 블록빌딩 블록은 DDD를 코드로 구현할 때 복잡도를 낮추기 위한 가이드라인입니다.📌 필수적인 개념은 아니지만, 직관적인 가이드 역할을 수행✅ 도메인을 표현하는 빌딩 블록Association (..
📌 과거의 DDD vs 현재의 DDD과거의 **도메인 주도 설계(DDD)**는 추상적인 개념과 철학적인 접근이 많았지만, 현재의 DDD는 보다 구체적이고 실용적인 형태로 발전했습니다.특히, 도메인의 범위를 구체화하고 솔루션까지 포함하는 형태로 변화했습니다.📌 현재의 DDD는 크게 두 가지 패턴으로 나뉩니다.1️⃣ 전략적 패턴 (Strategic Patterns) → 비즈니스 문제 공간(Problem Space)에서 도메인을 분리하는 과정2️⃣ 전술적 패턴 (Tactical Patterns) → 솔루션 공간(Solution Space)에서 도메인을 코드로 구체화하는 방법💡 즉, 문제를 이상적으로 나누고(디스틸레이션), 실제 구현에서 바운디드 컨텍스트를 어떻게 적용할 것인지 고민하는 과정이 포함됨.🔹..
🎯 개발과 정치가 만나는 곳: 전략적 설계소프트웨어 개발은 단순한 코드 작성이 아니라 조직의 구조, 협업 방식, 그리고 비즈니스 목표와도 맞물려 있는 전략적인 작업입니다.특히, 대규모 시스템에서는 여러 개의 도메인 모델을 다루는 것이 핵심이 됩니다.💡 전사(기업 전체)에 하나의 도메인 모델만 존재해야 할 필요는 없다!팀마다 도메인 모델이 다를 수 있음모든 도메인 모델이 중요한 것은 아니며, 중요한 곳에 집중해야 함❌ 실무에서 마주하는 문제들소프트웨어가 성장하면서 자연스럽게 복잡성이 증가하게 됩니다.🔹 응집도가 낮은 코드여러 팀이 함께 수정하다 보면 한 기능이 여러 도메인에 걸쳐 중복유지보수가 어려워짐🔹 기능 추가 & 코드 수정 시 충돌단일 도메인 모델을 사용할 경우, 수정 시 예상치 못한 사이드 ..
🔄 애자일과 도메인 주도 설계 (DDD)🎯 애자일(Agile)이란?초반에 정확한 일정 산정이 불가능목표를 달성하기 위해 계획을 계속 수정하는 방식현재 우리가 알고 있는 애자일과는 다소 다른 개념일 수도 있음💡 애자일이 등장한 이유?기존 소프트웨어 개발 방식은 건축이나 제조업에서 가져온 설계 방식을 따름하지만 소프트웨어는 하드웨어와 다르게 개발 중에도 지속적으로 변경됨변경을 수용하는 방식이 필요했음 → 애자일 등장✅ 애자일은 속도가 아니라 변경에 기민한 것!🤔 문제: 흐릿한 요구사항소프트웨어 개발에서는 처음부터 요구사항을 100% 명확하게 정의하는 것이 불가능함.🔹 개발 중 배워가는 과정프로젝트를 진행하면서 레거시 코드, 도메인, 사용자 니즈 등을 학습하게 됨초반에 예상했던 요구사항과 다르게 변할..
🚀 객체지향 설계에서 도메인 주도 설계로📌 객체지향 커뮤니티에서 DDD 철학이 등장객체 모델링을 실무 소프트웨어 프로젝트에 어떻게 적용할 것인지에 대한 논의객체지향 프로그래밍과 DDD가 함께 발전🕰 1990~2000년대: OOP와 DDD의 등장 배경🔹 1) 객체 지향이 유행하기 시작한 이유?GUI(Graphical User Interface)의 등장객체지향은 UI와 잘 맞는 패러다임이벤트(메시지) → 특정 UI(객체) 변경즉, OOP는 클라이언트 개발에 적합한 패러다임🔹 2) CS(Computer Science) 분야의 변화웹(Web) 개발의 대두이전까지는 로컬 컴퓨터 내에서 리소스를 사용웹이 등장하면서 네트워크, 분산 시스템 관련 기술이 필수 요소로 변화분산 객체 기술의 유행네트워크를 통해 다..
이 포스팅은 https://edu.nextstep.camp/s/yShtEl3D '도메인 주도 설계의 사실과 오해 8기' 강의를 듣고 내 언어로 정리한 포스팅이다. DDD 강의를 듣게 된 이유는 아는 개발자분의 추천이 있었기 때문인데, 협업에 적용을 원하는 경우는 아니었고 기술적 대화를 할 때 해당 주제가 나온다면 어떤 것인지 이해하고 각 상황에 도입이 필요할지 아닐지를 판단하는 사고를 키우고 싶었기 때문이다. 🚀 OOP와 DDD의 차이점🎯 OOP (객체 지향 프로그래밍)요구사항을 해결하기 위해 코드의 배치를 결정하는 방식유지보수를 쉽게 하기 위해 SOLID 원칙, 응집도 & 결합도, 의존성 통제, 사이드 이펙트 최소화 등을 고려프로그래밍을 어떻게 설계하고 구조화할 것인지에 대한 접근 방식🎯 DDD..