일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Google Cloud Platrofm
- Cloud Datastore
- Google Cloud
- ansible
- Cloud SQL
- container
- AWS
- 아마존웹서비스
- Solution Architect
- Google Cloud Platform
- kubernetes
- Amazon Web Service
- Solution Architect Certificate
- Google Cloud Platorm
- VPC
- 앤서블
- AWS Database
- 리버스 프록시
- Reverse Proxy
- gcp
- Kubernetes Engine
- Cloud Bigtable
- playbook
- GKE
- AWS Solution Architect
- AWS Certificate
- Cloud Spanner
- AWS 자격증
- Cloud Storage
- Compute Engine
- Today
- Total
목록development/architecture (3)
sungwony
대안은 무엇인가? SRP(단일 책임 원칙)와 DIP(의존성 역전 원칙) 부터 시작해보자 단일 책임 원칙 일반적 해석 하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다 실제적 정의 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다 아키텍처에서는? 컴포넌트를 변경할 이유가 한 가지라면 어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요가 없다는 것 이것은 의존성에 의해 너무도 쉽게 깨진다 부수효과에 관한 이야기 컴포넌트의 부수효과로 인해 소프트웨어를 변경하는데 더 많은 비용이 지불된다 의존성 역전 원칙 계층 간 의존성은 항상 다음 계층인 아래 방향 영속성을 변경 → 도메인도 함께 변경된다 의존성을 어떻게 제거할 수 있을까? 의존성 역전 원칙 ..
계층 구조 Q. 계층형 아키텍처의 문제점은 무엇인가? 코드에 나쁜 습관이 스며들기 쉽다 시간이 지날수록 소프트웨어를 변경하기 어렵다 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다 모든 것이 영속성 계층을 토대로 만들어진다 애플리케이션의 목적 비즈니스를 관장하는 규칙, 정책을 반영한 모델을 생성해 편의성을 높이는 것 상태(state)가 아니라 행동(behavior)을 중심으로 모델링한다 행동이 상태를 바꾸는 주체 그런데 왜? 도메인 로직이 아닌 데이터베이스를 토대로 아키텍처를 만드는가 우리는 도메인 로직을 먼저 만들어야 한다 그래야 우리가 만드는 로직을 제대로 이해했는지 확인할 수 있다 그리고 이를 기반으로 영속성 계층과 웹 계층을 만들어야 한다 ORM이 원인이다? ORM에 의해 관리되는 엔티티들은 ..
계층형(layered) 아키텍처 스타일의 단점 클린 아키텍처 육각형 아키텍처(Hexagonal Architecture) 도메인 중심 아키텍처의 장점 → 이후 육각형 아키텍처의 실습 학습 목표 계층형 아키텍처를 사용했을 때의 잠재적인 단점 아키텍처 경계를 강제하는 방법 잠재적인 지름길(?)들이 소프트웨어 아키텍처에 어떤 영향을 미칠 수 있는지 언제 어떤 스타일의 아키텍처를 사용할 것인지 아키텍처에 따른 코드 구현 아키텍처의 각 요소들을 포함하는 다양한 종류의 테스트 예제 코드 GitHub - wikibook/clean-architecture: 《만들면서 배우는 클린 아키텍처》 예제 코드 서문 클린 아키텍처 이론은 알겠지만?! → 선행 공부 했어야 하나? 클래스 간의 의존관계가 어느 정도로 허용되어야 하는지..