새의 눈도 벌레의 눈도 가지기 위한 모듈(패키지)

전체에 의해 압도되지 않고 모듈 내부의 상세를 볼 수 있고, 한편, 내부의 상세를 무시한 다음 모듈간의 관계성을 볼 수도 있다.

즉 새의 눈도 벌레의 눈도 가지고 있는 모듈.



사물의 전체를 보고 있는 것만으로는 세부 사항은 모르고, 부분에 주목하는 것만으로는 전체성을 잃는다. ( 학습 패턴 No.19 새의 눈과 벌레의 눈 부터)

모듈은 도메인을 배우는 데 필수적이라고 생각합니다.

모델로서의 모듈

도메인 계층의 모듈은 모델에서 의미있는 부분으로 나타나며 더 큰 척도로 도메인에 대해 이야기해야합니다 (2 부 5 장부터).

정리를 위해 모듈이나 패키지를 활용하는 팀은 많다고 생각합니다만, 도메인 중심으로 설계하고 있는 팀에서도, 모델로서 취급하고 있는 팀은 적을지도 모릅니다.

"도메인을 말해야 한다"는 것은 그대로의 의미일까 생각합니다.

예를 들어,

모델
|---- item
|---- member
|---- 주문

라는 폴더 구성이라면, ""회원"이 "상품"을 "주문"한다"라고 말하는 것입니다( ･ิω･ิ)

모델이 이야기라고 하면 모듈은 장에 해당한다. (제2부 제5장부터)

그리고 이것은 새의 눈을위한 모듈입니다.

예를 들어, 멤버를 보면 벌레의 눈으로 모델을 확인할 수 있습니다.

모델
|---- item
|---- member
| |____ Name.java
| |____ Contact.java
| |____ Profile.java
| |____ ***.java
|---- 주문

마법의 넘버 7±2

모듈을 모델링함으로써 모델링과 설계를 작은 모듈 단위로 처리할 수 있습니다.
인간이 한 번에 기억할 수 있는 수는 7개 전후라고 합니다.
이런 것도 의식해 보면 좋을지도 모르겠네요.

응집도와 결합도 및 패키지도

관련 모델을 모듈에 수집하고 관련 얇은 모델을 느슨하게 결합하기 위해 다른 모듈로 이동합니다.
응집도와 결합도는 오브젝트 지향의 기본 패턴이군요.
그것을 모듈에도 적용합니다.

패키지 다이어그램을 작성하는 것이 좋습니다.

리팩토링

모듈은 모델의 일부에도 불구하고 초기에 설계한 후에는 그다지 변경되지 않습니다.
그러나 모델은 변화하고 진화하는 것. 모듈을 수정하는 것은, 소스 코드를 수정하는 것보다 임팩트가 있습니다만, 모델의 진화에 맞추어, 리팩토링해 가는 것이 중요.

충돌을 일으키거나 하는 것도 많이 있을까 생각합니다만, 치아를 먹고 잠시 리팩토링합시다.

지금의 프로젝트에서도 여러 번 모듈을 변경했습니다. 혼자서 리팩토링해도 영향이 크고, 그동안 아무도 소스를 어리석은 것 같았기 때문에, 모듈을 변경할 때에는 전원이 모여, 그 자리에서 변경해 버리고 있습니다. 몹 프로그래밍적인 프랙티스군요.