여기서는 앞서 살펴본 의사 앱(Doctor App)에 대해 각 Layer의 모듈 내부에서 찾을 수 있는 일반적인 요소를 살펴보겠다.
의사 앱(Doctor App) 아키텍처 캔버스의 모습이다.
각 모듈의 일부인 실제 요소를 확인하겠다.
Foundation Modules에서 의사 모바일 애플리케이션용 테마(Doctor App Theme) 모듈부터 시작하겠다.
여기에는 공통 역할 및 기본 제공 로그인 논리 요소가 있어야 한다.
인터페이스는 모바일 로그인을 지원하기 위한 레이아웃, 예외 흐름, UI 화면을 정의한다.
플래너 웹 애플리케이션용 테마(Planner Themes) 모듈과 관련하여 예상되는 요소는 의사 모바일 애플리케이션용 테마(Doctor App Theme) 모듈과 동일하다.
유일한 차이점은 인터페이스 요소에 대한 모바일 로그인 UI 대신 웹 로그인 UI이다.
이제 푸시 알림(Push Notifications Plugin) 모듈을 살펴보겠다.
데이터 요소 측면에서 입/출력 구조가 있어야 하며 애플리케이션에 액세스하는 장치의 플러그인 설정을 유지해야 한다.
논리 요소 측면에서 알림 및 유효성 검사를 처리하는 작업이 있어야 한다.
구글 캘린더(Google Calendar) 모듈의 경우 캘린더 작업을 처리하는 데 필요한 논리뿐만 아니라 입력/출력 구조와 캘린더 엔티티가 데이터 요소로 필요하다.
Google 인터페이스를 처리하기 위한 정규화된 API 및 UI 위젯의 동작을 지원하는 예외 처리기가 있어야 한다.
이것은 인터페이스 요소이므로 여기에서 다른 화면에서 사용할 재사용 가능한 UI 위젯을 찾을 수 있다.
마지막으로 문자 메시지(Text Message) 모듈을 살펴보겠다.
외부 문자 메시지 서비스 및 TextMessage 구성 엔터티를 처리하는 정규화된 API를 지원하는 I/O 구조만 있는 이전 항목과 매우 유사하다.
논리 요소로 텍스트 메시지 작업을 처리하는 CRUD 작업, 외부 서비스를 처리하기 위해 논리를 캡슐화하는 정규화된 API 및 예외 처리기가 있다.
이제 Core Layers와 의사 모바일(Doctor Mobile) Business Logic 모듈로 이동하겠다.
데이터 요소로는 정의된 요구 사항에 최적화된 로컬 저장소, 임시 및 특정 화면 데이터, 세션 정보 및 등록 프로세스가 예상된다.
이러한 데이터 엔터티가 공개되어야 하는 경우 읽기 전용으로 설정해야 한다.
논리 요소 측면에서 권한이 있는 사용자만 특정 작업을 수행할 수 있도록 CRUD 서버 작업과 역할 작업을 확인한다.
CRUD 작업은 데이터 조작 방법을 정의한다.
서버에서 장치로 데이터를 동기화하는 논리도 여기에서 정의된다.
프로세스 요소 측면에서 불필요하거나 임시 데이터를 삭제하려면 정리 작업이 필요하다.
약속(Appointment) 논리 모듈의 경우 공용 읽기 전용 약속 데이터 요소가 있다.
논리 요소 측면에서 약속 논리 작업, CRUD 작업 및 비즈니스 규칙 작업이 있을 수 있다.
이것은 약속이 생성되는 모듈이므로 의사의 의제를 생성하거나 확인하고 알림을 보내려면 타이머 또는 비즈니스 프로세스가 필요할 수 있다.
정보 유지 관리를 지원하는 정리 작업도 프로세스 요소로 있을 수 있다.
Core Services 모듈과 관련하여 대부분 데이터 요소와 해당 논리 요소가 예상된다.
각각의 CRUD 작업 및 비즈니스 로직이 있는 읽기 전용 비즈니스 엔터티를 의미한다.
Core Widgets 모듈은 UI 블록을 지원하기 위한 논리 요소의 정의를 보유한다.
이는 이러한 모듈 내부에 실제 위젯 또는 블록도 있음을 의미한다.
이제 다시 한 번 End-User Layer과 Doctor 앱 End-User Modules로 이동해 보겠다.
여기서 예상되는 인터페이스 요소는 보조 구조와 임시 데이터 요소는 물론 이를 지원하는 화면 유효성 검사 작업과 같은 논리 요소가 있는 모바일 화면이다.
Appointment Planner End-User Modules의 경우 이전 Doctor App 최종 사용자 모듈과 동일한 요소가 있을 수 있다.
Doctor 앱 End-User Modules과 차이점은 모바일 화면 대신 인터페이스 요소로 웹 화면이 있다.
