애플리케이션 아키텍처란 무엇인가요?

애플리케이션 아키텍처 조직이 소프트웨어를 구축하는 방법을 결정하는 데 사용하는 패턴과 기술의 집합입니다.

애플리케이션 구성 요소 간의 상호 작용을 정의합니다. 또한 미들웨어 및 데이터베이스와 같은 핵심 서비스와 관련된 상호 작용을 정의합니다. 아키텍처는 조직, 산업 또는 애플리케이션 유형에 따라 다를 수 있습니다.

건축은 주택의 건축이 인테리어 디자인과 다른 것과 같은 방식으로 소프트웨어 디자인과 다릅니다. 소프트웨어 디자이너는 건축 원칙의 기초에 기반하여 디자인을 만듭니다. 건축은 디자인을 안내하는 일련의 가드레일입니다.

대부분의 엔터프라이즈 애플리케이션 아키텍처는 세 가지 기본 계층을 통합합니다.

1. 따라서 데이터베이스 계층 서버, 데이터베이스, 네트워크, 스토리지, 미들웨어와 같은 저수준 종속성과 관련된 모듈이 포함되어 있습니다.
2. 따라서 비즈니스 계층 비즈니스에 특화된 논리 규칙을 설정하는 모듈이 포함됩니다. 예로는 통화 계산, 워크플로, 애플리케이션 인터페이스 및 데이터 모델이 있습니다.
3. 따라서 프레젠테이션 계층 사용자가 애플리케이션과 상호작용하는 방식을 정의합니다. 예로는 메뉴 구조, 탐색 체계, 버튼과 같은 대화형 구성 요소의 배치가 있습니다.

사용될 수 있는 다른 레이어의 예는 다음과 같습니다.

• 기능 계층: 비즈니스 규칙에 따라 시스템이 어떻게 동작하는지 지정합니다.
• 애플리케이션 핵심 계층: 데이터베이스 위에 위치합니다

건전한 건축 원칙은 각 계층이 아래 계층과 통신할 수 있지만 위 계층과는 통신할 수 없다고 명시합니다. 이 규칙은 복잡성을 증가시키고 소위 "스파게티 아키텍처"를 초래할 수 있는 종속성을 만드는 것을 방지합니다.

왜 애플리케이션 아키텍처가 필요한가요?

몇 가지 이유가 있습니다. 응용 프로그램의 아키텍처 중요하다:

• 일관되게 사용되고 액세스되는 서비스 집합을 제한함으로써 복잡성을 줄입니다.
• 중복성과 기술의 확산을 제한하여 비용을 절감합니다.
• 기존 애플리케이션을 수정할 때 다른 사람들이 따를 수 있는 일관된 로드맵을 만듭니다.
• 다양한 유형의 애플리케이션에 가장 적합한 서비스를 명시함으로써 효율성을 향상시킵니다.

예를 들어, 권장 사항에는 트랜잭션 애플리케이션을 위한 특정 관계형 데이터베이스 관리 시스템이 포함될 수 있습니다. 마찬가지로 개발자는 애플리케이션 아키텍처에 따라 분석 용도로 특정 NoSQL 데이터베이스를 선호할 수 있습니다.

엔터프라이즈 애플리케이션 아키텍처 모범 사례

엔터프라이즈 애플리케이션 아키텍처는 합의 중심입니다. 모든 사람이 소프트웨어를 지정하고 구축하는 데 참여하며 정의와 서비스에 동의합니다. 효과적인 애플리케이션 아키텍처:

• 시간의 시험을 견뎌냅니다
• 조직의 소프트웨어 개발 방법을 강화합니다
• 유연성을 극대화하고 복잡성을 최소화합니다. 기술 부채

엔터프라이즈 아키텍처 모범 사례는 규모와 속도 모두에 대한 재사용성을 극대화합니다. 또한 통신 조건을 지정하여 계층 간 종속성을 최소화해야 합니다.

예를 들어, 데이터베이스 계층은 깨지지 않는 종속성을 만드는 것을 피하기 위해 프레젠테이션 계층의 기능에 의존해서는 안 됩니다. 또한 여러 사용자를 동시에 수용하기 위해 프레젠테이션 계층에서 최종 사용자 서비스를 격리하는 것도 중요합니다. 이 규칙은 또한 사용자 세션이 이웃의 비즈니스 또는 데이터베이스 서비스에 의존하는 것을 방지합니다.

레이어 내에서도 공동 의존성을 최소화합니다. 예를 들어, 계약과 고객은 긴밀하게 관련되어 있지만, 각 요소는 다른 요소 없이도 존재할 수 있어야 합니다. 종속성이 필요한 경우, 요소를 단일 모듈로 결합합니다.

레이어에 포함할 모듈을 신중하게 선택하세요. 데이터베이스 레이어에서 비즈니스 규칙을 정의하지 말고, 비즈니스 레이어에서 데이터베이스 규칙을 정의하지 마세요. 비즈니스 레이어 모듈은 인증이나 검증 검사와 같은 일반적인 목적의 작업이 아닌 회사의 비즈니스에 특정한 기능으로 제한되어야 합니다.

원칙적으로 프레젠테이션 계층과 데이터베이스 계층 간의 직접적인 상호 작용을 피하십시오. 안전한 접근 방식은 공개 데이터를 읽기 전용으로 노출하고 보안 제어에 따라 업데이트를 하는 것입니다.

7가지 유형의 엔터프라이즈 애플리케이션 아키텍처

개발자에게 제공되는 옵션 범위가 확대됨에 따라 아키텍처 유형이 증가했습니다. 가장 일반적인 엔터프라이즈 아키텍처 사례는 다음과 같습니다.

1. 모놀리식 아키텍처

모놀리식 아키텍처는 일반적으로 다음과 연관됩니다. 레거시 시스템 현대 서비스 지향 구조가 사용 가능하기 전에 개발되었습니다. 이 아키텍처에서는 모든 기능이 자체적으로 포함됩니다. 모든 변경 사항에서 팀은 소프트웨어를 테스트하고 다시 컴파일해야 합니다.

모놀리식 소프트웨어는 복잡하고, 확장성이 좋지 않으며, 업데이트하기 어렵습니다. 그러나 간단한 기능과 트래픽이 적은 도구를 갖춘 소규모 프로젝트에 유용합니다. 허용되는 사용 사례의 예로는 웹 계산기와 블로그가 있습니다.

2. 서비스 지향 아키텍처

서비스 지향 아키텍처는 1990년대에 등장하여 현대 마이크로서비스로 진화했습니다. 이 접근 방식은 애플리케이션을 개별적이고 재사용 가능한 서비스로 나눕니다.

이러한 서비스는 공통 엔터프라이즈 서비스 버스를 통해 서로 통신합니다. 메시지 큐잉 또는 게시 및 구독 기술을 사용하여 메시지를 교환합니다. 비동기 적으로.

3. 마이크로서비스 아키텍처

마이크로서비스 아키텍처는 DevOps와 같은 클라우드 네이티브, 애자일 개발 환경에서 사용됩니다. 이 접근 방식은 애플리케이션을 다음과 같은 가장 작은 가능한 구성 요소로 나눕니다.

• 느슨한 결합
• 기능적으로 독립적
• 재사용

개발자는 마이크로서비스에서 애플리케이션을 조립하여 신속한 소프트웨어 개발이 가능합니다.

결과적으로 나오는 애플리케이션은 잘 확장됩니다. 또한 회복성이 있습니다. 개별 서비스의 실패가 전체 애플리케이션을 다운시키지 않습니다. 또한 중단 없이 개선 사항을 도입할 수 있습니다. 여러 개발자가 동일한 애플리케이션에서 동시에 작업할 수 있습니다.

4. 이벤트 기반 아키텍처

이벤트 기반 아키텍처는 실시간 처리 및 셀프 서비스 시나리오에서 널리 사용됩니다. 미리 정의된 일정에 따라 데이터 배치를 처리하는 대신, 이벤트 기반 아키텍처는 버튼 누르기나 신용카드 긁기와 같은 이벤트에 응답합니다.

이벤트 기반 애플리케이션은 이벤트가 해당 작업과 관련된 특정 작업 집합을 시작하기 때문에 종종 마이크로서비스 아키텍처 위에 구축됩니다.

5. 웹 애플리케이션 아키텍처

웹 애플리케이션 아키텍처는 브라우저와 모바일 애플리케이션에서 실행되는 프로그램에 특화되어 있습니다. 인터넷의 분산된 특성의 맥락에서 사용 가능한 구성 요소와 논리적 상호 작용을 정의합니다.

브라우저 기능이 향상되면서 웹 애플리케이션 아키텍처는 더욱 미묘해졌습니다. 예를 들어, 프로그레시브 웹 앱은 모든 브라우저에서 작동하며 인터넷 연결 없이도 풍부한 기능을 제공합니다.

웹 앱 아키텍처는 로직과 사용자 인터페이스 요소를 저장할 위치는 물론, 웹 페이지 요소가 로드되는 순서도 결정할 수 있습니다.

6. 모바일 애플리케이션 아키텍처

모바일 애플리케이션 아키텍처는 웹 앱과 비슷하지만 모바일 기기의 더 큰 처리, 메모리 및 저장 용량을 갖추고 있습니다. 또한 플랫폼 간 이식성을 위한 구조를 지정합니다.

7. 서버리스 아키텍처

서버리스 아키텍처는 마이크로서비스 모델의 가장 최근 진화이며 여전히 비교적 드뭅니다. 이 접근 방식을 사용하면 소프트웨어 컨테이너 내부의 클라우드 기반 타사 서비스가 애플리케이션을 구성합니다.

서버리스 기능은 잘 확장되며 매우 빠르게 스핀업하고 종료할 수 있습니다. 서버리스는 클라우드 인스턴스가 불필요하기 때문에 소프트웨어를 배포하는 가장 저렴한 방법 중 하나이기도 합니다. 인기 있는 용도는 다음과 같습니다.

• 이벤트 처리
• 이미지 인식
• 자동화 된 소프트웨어 테스트
• 기계 번역

올바른 엔터프라이즈 애플리케이션 아키텍처를 선택하는 방법

모든 사용 사례에 적합한 단일 아키텍처는 없지만 대부분은 여러 시나리오에 맞을 만큼 유연합니다. 필요한 기능부터 시작하여 기본 플랫폼으로 내려가면 선택 범위를 좁힐 수 있습니다.

어떤 경우에는 여러 아키텍처의 요소를 결합해야 할 수도 있습니다. 올바른 아키텍처를 결정할 때 고려해야 할 몇 가지 요소는 다음과 같습니다.

선택은 당신의 것입니다

오늘날 조직은 소프트웨어를 구축하는 데 있어 그 어느 때보다 더 많은 선택권을 가지고 있습니다. 선택권이 마비를 일으킬 수 있지만, 개발팀이 DevOps 기술과 최신 클라우드 네이티브 기술로의 전환을 시작하는 것을 주저할 이유는 없습니다.

강력한 엔터프라이즈 애플리케이션 아키텍처는 출시되는 새로운 기술을 수용해야 하며 기존의 "폭포수" 개발 및 애자일 방식에 적합해야 합니다.

개발팀은 계층과 규칙을 정의하는 건전한 관행을 준수함으로써 적응 가능하고 미래에도 적응 ​​가능하며 근본적으로 견고한 아키텍처를 만들 수 있습니다.