컨텍스트 경계 및 디렉토리 구성 고려

이 글에는 베어 고유의 이슈가 잘 나오지 않지만, 베어 앱을 만들 때의 생각을 적었다.
개시하다
BEAR.Resource는 REST 제약 하에 애플리케이션의 정보와 기능을 리소스로 사용합니다.
실무 실현에서 아래 그림에서 보듯이 자원은 기본적으로 프레임워크족의 구성 요소(예를 들어 창)나 특정한 비즈니스 구성 요소에 의존한다.

[リソース] -- depends --> [フレームワークファミリのコンポーネント] or [ビジネスコンポーネント]

사용자 여러분, 디렉터리 구성은 어떻습니까?여기서 고려한 것은 범위와 상하문 경계의 디자인이다.나는 두 가지 디자인 방법이 있다고 생각한다.
예로 들다

「商品を注文するショッピングサイトを作る」

이 문제를 고려해 보아라.
방법 1: 컨텍스트 경계를 디렉토리로
이 예에서 지난번 보도에서 나는 이렇게 해 보았다. (그러나 대부분의 사람들은 이렇게 하지 않을 것이다. 어때?!)

자원과 같은 등급의 고위층에 비즈니스 구성 요소의 채널을 설치했다(비즈니스 명칭이'Example'인지 알기는 어렵지만 여기에 고유의 포장 명칭이 있다는 인상을 준다.)아래 그림에서 보듯이 각 상하문에는 프레임족의 구성 요소(Form의 구상류 등)와 자체 제작된 비즈니스 구성 요소가 걸려 있다.

4

특징: 수직 관리 업무로 복잡성을 견디기 쉽다.
방법2: 프레임워크가 제공하는 유형(구성 요소)을 디렉터리로 직접
틀 학습 교재로서 이 방법은 더욱 직관적이고 이해하기 쉽다.

나는 이것이 기초형 기초의 수준 관점이라고 생각한다.
(※ 주제 밖의 말, DDDD책을 공부하는 사람들이 [Domaain]이라는 목록을 최고층에 놓고 유형에 따라 목록을 나누는 예를 자주 볼 수 있다. 이것도 분류의 일종이다.)
끝말
아무래도 카탈로그 구성은 일단 앱이 만들어지면 바꾸기 어려운 부분이기 때문에 디자인 대상으로서 먼저 생각해야 하고 논의의 여지가 있는 부분이라고 생각한다.
문장을 인용하다

[※1] BEAR 브로셔 - 자료