소프트웨어 아키텍처는 아키텍처 특성, 아키텍처 결정, 설계 원칙, 시스템의 구조로 구성됩니다. 아키텍처 특성 아키텍처 결정 설계 원칙 시스템의 구조 시스템의 구조란 시스템이 구현된 아키텍처 스타일들 (마이크로서비스, 레이어드 등)의 종류를 말합니다.
엔지니어링 프랙티스는 가시적이고 반복 가능한 혜택을 주는 실천론을 의미합니다. 예를 들어 지속적 통합 (Continuous Integration)는 특정 프로세스에 의존하지 않는 검증된 엔지니어링 프랙티스입니다. 소프트웨어 프로세스는 팀을 어떻게 구성하고 관리할지, 회
소프트웨어 구축에서 의사 결정은 매우 중요합니다. 소프트웨어 품질과 프로젝트의 성공 여부는 결정의 품질에 달려있다고 표현해도 과언이 아닙니다. 팀은 항상 팀이 가진 정보, 경험, 재능을 바탕으로 최선의 결정을 내리지만 변수가 발생하면 결정도 변해야 합니다. 어떤 결정은
아키텍처 사고란 아키텍처 관점에서 사물을 바라보는 것입니다. 아래와 같은 활동은 아키텍처 사고에 해당합니다.아키텍처와 설계의 차이를 이해하고, 어떻게 개발팀과 협력해야 할지 고민하는 것기술의 깊이를 유지하면서 폭넓은 기술 지식을 확보하는 것다양한 솔루션과 기술 간의 트
응집이란 무엇입니까 Cohesion은 한 모듈의 구성 요소가 동일한 모듈 안에 얼마나 포함되어 있는지를 나타냅니다. 즉, 모듈을 구성하는 요소들이 얼마나 서로 연관되어 있는가에 관한 것입니다. 응집도의 측정 범위 기능적 응집 (Functional Cohesion)
각 계층에서 하던 일들을 "내부"와 "외부"라는 개념으로 나누어 각각에 맞는 별도의 인터페이스를 정의 - 어댑터와 포트내부의 로직은 외부을 통해서만 접근 가능모든 외부 시스템과의 직접적인 상호작용은 "어댑터"의 역할각 서비스에서 비즈니스 로직에 맞게 정의된 인터페이스는
중앙 집중식 인증: 모든 마이크로서비스가 동일한 인증 메커니즘 (keycloak에 의존하기 때문에) 을 사용할 수 있어 일관성이 유지됨보안 강화: 인증, 인가 로직을 각 마이크로서비스가 아닌 keycloak 서비스에서 중앙 집중식으로 관리하므로 보안에 유리사용자 관리의