소개

에릭 에반스의 도메인 중심 설계 (2004)의 제 8 장 "브레이크 스루"를 읽고 자신이 이해한 것을 내보내기
상당히 자신의 생각과 섞여 버리고 있으므로, 여기에 써 있는 것 이콜 책의 내용은 아닙니다

자신의 이해가 부족한 곳이나 이상한 곳은 바시바시 돌진하고 싶습니다

기타 요약

제3장 「모델과 실장을 연결한다」

제4장 "도메인 격리"

제5장 「소프트웨어로 표현된 모델」

제6장 "도메인 객체의 라이프 사이클"

제8장 「브레이크스루」

대상자

오래된 시스템에서 재생하는 사람

출시 우선 순위로 만들 때 위험을보고 싶은 사람

디자인하지 않고 분위기에서 물건을 만드는 사람

에릭 에반스의 책을 읽으면 견딜 수없는 졸음에 습격당하는 사람

자꾸 무슨 이야기?

작은 리팩터를 반복적으로 만들어 봅시다.
그렇게 함으로써 모델이나 설계가 명확해지고, 이러한 명확성이 브레이크스루의 전조가 됩니다

브레이크 스루가 방문했을 때 리팩터를 실시할지 여부를 판단합시다.
브레이크 스루를 넘어서면 도메인 모델을 깊은 모델에 가깝게 할 수 있어 어느 단계에서 개발 페이스는 가속해 갑니다
그러나 대부분의 프로젝트는 이미 구축한 것의 양과 복잡성에 발을 잡혀 움직임을 잡을 수 없게 됩니다.

이러한 브레이크 스루가 있다는 것을 이해하고 가능하면 준비해 둡시다.

도메인 모델을 유지 보수 할 때 방문하는 브레이크 스루에 대한 이야기였습니다.
이후에는 중요하다고 생각한 브레이크 스루에 대해 깊이 파고 갑니다

브레이크 스루

브레이크 스루는 본질적인 과제를 깨는 혁신적인 솔루션 (wiki)

다음은 도메인 모델을 유지 관리하는 동안 방문하는 획기적인 방법에 대해 설명합니다.

언제 일어날 것인가?

브레이크 스루를 의도적으로하는 것은 어려움
그러므로 브레이크 스루를 일으키려고 하는 것이 아니라 일어날 수 있는 환경 만들기, 일어났을 때에 대응할 수 있도록 준비하는 것이 좋을 것 같습니다

브레이크 스루는 적절한 리팩토링을 반복 할 때 나오는 것이므로 리팩토링을 수행하는 문화를 만듭니다

브레이크 스루가 발생했을 때 기능을 담보하기위한 행동 테스트 준비

사전에 공수가 부풀어 오르는 타이밍이 있다는 것을 상장이나 멤버에게 이해하게 한다
등

판단

대부분의 리팩터보다 효과가 크다

위험을 허용 할 수 있습니까?

위험을 씻어서 하나씩 판단

타이밍에 괜찮습니까?

시간, 리소스 등

판단축은 상기와 같다.

마지막으로

이 장에서는 브레이크 스루가 방문하는 장이었습니다.
이후의 장에서 실제로 어떻게 대응하는지 등 자세한 사항에 접할 수 있다고 생각합니다

개인적으로는 브레이크 스루가 왔을 때에 잘 극복하고 싶기 때문에, 사전에 준비할 수 있는 것은 어쩔 수 없다고-라고 생각했습니다
이 장은 내용적으로 상당히 얇았기 때문에 이상이 됩니다.
미안해.