개인 노트: DDD 모듈 및 기타 모듈 및 하위 모듈, 패키지 및 리포지토리 정보

목적

이 기사의 목적은 DDD의 domain model이나 모듈을 구축할 때 보다 잘 구축할 수 있도록 이해를 돕기 위한 전제지식을 정리하기 위한 내용입니다.

모듈이란?

원래 모듈이란 무엇입니까?
위키 에서는 서두에 이렇게 쓰여져 있습니다.

모듈(영: module)이란, 공학 등에 있어서의 설계상의 개념으로, 시스템을 구성하는 요소가 되는 것. 몇 가지 부품적 기능을 모아서 일관된 기능을 가진 부품. 모듈을 따르는 것을 모듈러(영: modular)라고 한다.

과연, 즉 「기능」의 「집합」이고, 그 「기능」의 「집합」은 시스템을 구성하기 위한 요소이다.

이 경우의 「기능」과 「집합」은 맞는 글자처럼 A와 B 같은 느낌으로 사용되고 있는 곳을 자주 보입니다.

일단 js와 파이썬에서도 module를 구현하고 있습니다.
파이썬의 경우 모듈은 "재사용"을 달성하기 위해 있다고합니다. js도 어쩌면 비슷한 것입니다.
js와 python의 맥락에 한해서 말하면 import 할 수있는 녀석이 module 자신입니다.
이 경우의 module는, 「함수나 클래스, 변수등」의 「집합」입니다.
이 구조에 의해, 「재이용」 「배포」 「클래스명의 충돌 회피」...etc등의 혜택을 받을 수 있습니다.

그러나, js와 python이 「함수나 클래스, 변수등」의 「집합」같다고 해서, 다른 언어나 설계, 문맥에서는 module의 구체적인 의미가 다른 것은 자주 있습니다.

DDD의 맥락에서도 module라는 용어는 나옵니다.
자신은이 module === 파이썬 패키지 시스템으로 받았지만 DDD는 특정 언어에 의존하지 않습니다.
'파이썬'이라고 생각하는 시점에서 파이썬에 의존하는 마음이었다는 것입니다.

그럼, 「DDD의 문맥이 말하는 module」이란

DDD가 말하는 module은 「개념」의 「응집」이며, 그 「개념」의 「응집」은 시스템을 구성하기 위한 요소입니다.
DDD의 문맥이 말하는 module는, 「개념의 응집성」과 「개념끼리의 소결합성」을 실현하기 위한 디자인 패턴과 같습니다.



이 그림의 경우는 전원 탭도 물론 요리로 사용하는 케이스는 있습니다만, 키친 서랍과 차고 공구 상자의 어느 쪽에 넣을까라고 하면, 차고 공구 상자가 더 가까울까라고 생각합니다. 어쩌면 향후에는 더 적합한 모듈이 나오고 거기에 넣을 가능성도 있습니다.

여기에서 다음 내용은 파이썬과 js에서 모듈과 패키지의 메모입니다. DDD와는 무관하다

서브 모듈 정보

자바 스크립트와 파이썬의 경우도 마찬가지로 특정 import 할 수있는 놈보다 깊은 곳에있는 import 할 수있는 사람이 서브 모듈

보충

module은 중첩됩니다.
import 'A'도 가능하면 import 'A/B'도 import 'A/B/C'도 가능
A도 모듈에서 B와 C는 A의 서브모듈로 만들어지는 경우가 많다.

패키지에 대해 (클린 아키텍처 책이라고 컴포넌트라고 불리고

조금 전 보충에서는 import 'A'가 가능하다고는 했지만, 할 수 없는 경우도 있다.
그것의 구체예가 이하와 같은 구성의 경우이다.
htps //w w. 음 pmjs. 코 m / Pac 카게 / @ ゔ 에 / c ぃ - ぅ 긴 - 2 에 - cyp
htps : // 기주 b. 코 m / ゔ 에 js / ゔ 에- c ぃ / t 에 /에서 v / 파 쿠 케 s / % 40 ゔ

이 경우라면 import 'A'는 할 수 없지만, import 'A/B'또는 import 'A/B/C'를 할 수 있는 일이 있다
이 경우 A는 모듈의 컨테이너 역할을하는 패키지이고 B는 모듈이고 C는 B의 하위 모듈입니다.

보충

기본적으로 하나의 git 저장소로 하나의 패키지를 만드는 경우가 많다.
하지만 ts의 @types이나 vue-cli의 @vue 등, 1개의 리포지토리로 복수의 패키지를 관리하는 것도 상당히 많다.

사례 연구

1. 이 디렉토리는 패키지입니다.

2. 이 파일은 모듈이다

3. 이 파일은 모듈이다

4. 이 파일은 3의 서브모듈이다