Designing Apps Using an Architecture Framework #4 - Designing an Architecture : An Example
특정 비즈니스 사례인 Doctors Appointments 앱에 아키텍처 설계 프로세스를 적용한 사례를 살펴보겠다.
설계 프로세스의 세 단계를 수행하면 Architecture Blueprint 및 Architecture Reference Map을 도출할 수 있다.
병원의 의사 예약을 관리할 수 있는 앱을 예로 살펴보겠다.
상단에 총 5가지 요구 사항을 확인할 수 있다.
공개(Disclose) 단계에서 빈 아키텍처 캔버스로 시작한다.
첫 번째 요구 사항부터 시작하여 지원해야 하는 최종 사용자 프로세스를 식별한다.
첫 번째 요구 사항은 "의사들은 의사의 어젠다와 환자의 검사를 보고 긴급한 케이스를 선택할 수 있어야 한다."이다.
여기서는 어젠다 보기(See Agenda), 검사 보기(See Exams), 긴급한 케이스 선택하기(Select Urgent Cases)가 사용자 프로세스 개념으로 도출될 수 있다.
이는 End-User Layer에서 포함되어야 한다.
"의사"는 시스템에서 매핑해야 하는 핵심 비즈니스 개념을 나타내기 때문에 의사(Doctor) 개념은 Core Layer의 일부여야 한다.
검사(Exam) 개념을 식별하고 각 검사(Exam)를 환자(Patient)와 연관시키는 것도 가능하다.
따라서 이 두 가지 개념도 모두 Core Layer에 속한다.
두 번째 요구 사항은 "의사들은 다른 병원의 다른 부서에서 일합니다."이다.
이미 대표되는 의사(Doctor) 외에도 부서(Unit)와 병원(Hospital)이라는 두 가지 개념을 더 확인할 수 있다.
이건 다시 Core Layer에서 구성된다.
세 번째 요구 사항은 "Google 캘린더가 약속을 나타내고 의사들의 가용성을 찾는 데 사용된다"이다.
여기서는 약속(Appointment)이라는 핵심 비즈니스 개념을 찾을 수 있다.
지정된 병원(Hospital)에서 특정 의사(Doctor) 및 특정 환자(Patient)와 약속(Appointment)이 생길 수 있다.
애플리케이션은 구글 캘린더(Google Calendar)와 상호 작용하여 약속(Appointment)을 나타내고 의사(Doctor)의 가용 여부를 확인해야 한다.
이는 외부 시스템과의 통합이므로 Foundation Layer의 일부여야 한다.
네 번째 요구 사항은 "새로 생기고 변경된 약속을 의사들에게 통보한다."이다.
이는 온라인 상태일 때 문자 메시지(Text Message) 또는 푸시 알림(Push Notifications Plugin)을 통해 이루지고 이는 외부 시스템에서 실행해야 한다.
따라서 이것 또한 Foundation Layer의 일부여야 한다.
마지막 요구 사항에서는 약속을 관리하는 웹 애플리케이션에 대해 알려준다.
이 경우 약속 플래너(Appointment Planner)라는 End-User Layer 개념이 하나 더 도출된다.
공개(Disclose), 구성(Organize) 단계가 끝났다.
프로세스의 다음 단계는 조립(Assemble) 단계이다.
여기서는 도출된 개념이 모듈로 변환되는 방식에 대해 확인해보겠다.
첫째, 의사 프로세스를 보면 이러한 프로세스에 대해 별도의 life-cycle이 필요하지 않기 때문에 동일한 모바일 모듈에서 함께 존재할 수 있다.
따라서 이 세 가지 개념을 의사 모바일 앱(Doctor App)에 조합한다.
검사(Exam) 개념은 자체 모듈에 있어야 한다.
의사(Doctor) 개념, 환자(Patient) 개념에서도 마찬가지이다.
다음은 두 개념을 단일 모듈로 병합할 수 있는 예이다.
부서(Unit)는 병원(Hospital)과 관련이 있기 때문에 병원(Hospital)이 없는 부서(Unit)를 다루는 것은 의미가 없다.
따라서 이 두 개는 병원(Hospital) 모듈이 된다.
약속(Appointment)은 다른 핵심 모듈을 오케스트레이션 하는 모듈이어야 한다.
모바일 애플리케이션을 만들고 싶다면 모바일 로컬 저장소도 필요하다.
이러한 이유로 모바일 장치와 서버 간의 로컬 데이터 및 정보 동기화를 처리할 의사 모바일(Doctor Mobile) 모듈도 만들어야 한다.
의사 모바일 앱(Doctor App) 및 약속 플래너(Appointment Planner) 웹 앱 모두에 대해 위젯 또는 블록이 필요합니다.
이러한 요소를 특정 모듈로 분리하는 것이 좋습니다.
여기서는 의사 위젯(Dcotor Widgets)과 약속 위젯(Appointment Widgets)으로 구분하였다.
구글 캘린더(Google Calendar)는 캘린더에 액세스 할 수 있는 기능을 제공한다.
그리고 문자 메시지(Text Message) 및 푸시 알림(Push Notifications Plugin) 모듈은 의사(Doctor)에게 알릴 수 있는 알림 기능을 제공한다.
이러한 작업은 서버 측의 통합 모듈을 통해 수행되어야 웹 및 모바일 애플리케이션에서도 이를 재사용할 수 있다.
마지막으로, 다른 테마를 가질 수 있다.
하나는 플래너 웹 애플리케이션용 테마(Planner Themes)이고 다른 하나는 의사 모바일 애플리케이션용 테마(Doctor App Theme)이다.
아키텍처 설계 프로세스 중에 식별된 모든 모듈을 표현하고 있다.
이를 아키텍처 청사진(Architecture Blueprint)이라고 하며 특정 계층에 있는 모든 모듈을 보여준다.
모듈 간의 종속성을 식별하면 화살표를 추가하고 아키텍처 참조 맵(Architecture Reference Map)을 얻을 수 있다.
- 각 최종 사용자 모듈은 해당 테마에 따라 다름
- 각 최종 사용자 모듈은 Core Layer의 각 위젯 모듈에도 의존함
- Doctor 모바일 앱(Doctor App)은 또한 third-party 푸시 알림 서비스에 등록할 수 있도록 푸시 알림(Push Notifications Plugin)에 의존함
- Doctor 모바일 앱(Doctor App)은 또한 로컬 스토리지 데이터를 위해 의사 모바일(Doctor Mobile) 모듈에 의존하며, 이는 차례로 의사(Doctor) 및 약속(Appointment) 모듈의 정보를 사용함
- 약속 플래너(Appointment Planner) 웹 앱은 약속을 관리하기 위해 약속(Appointment) 모듈을 참조함
- 약속(Appointment) 모듈은 병원(Hospital), 의사(Doctor), 검사(Exam) 및 환자(Patient) 모듈을 조율함
- 구글 캘린더(Google Calendar), 문자 메시지(Text Message) 및 푸시 알림(Push Notifications Plugin) 통합에 의존함
- 의사(Doctor) 핵심 모듈은 검사(Exam) 및 환자(Patient) 모듈에 따라 다름