도메인 기반 설계의 리팩토링 [닫기]

방금 프로젝트 작업을 시작했으며 우리는 도메인 중심 설계 ( 도메인 중심 설계 : 소프트웨어 중심의 태클 복잡성에서 Eric Evans가 정의한대로)를 사용하고 있습니다 . 우리 프로젝트는 확실히이 설계의 후보라고 생각합니다 에반스가 자신의 책에서 설명하는 패턴.

나는 끊임없이 리팩토링이라는 아이디어로 고심하고 있습니다.

리팩토링은 모든 프로젝트에서 필수적이며 소프트웨어가 변경 될 때 필연적으로 발생한다는 것을 알고 있습니다. 그러나 필자의 경험에 따르면 리팩토링은 도메인 변경에 대한 이해 (에반스가 말하는대로 더 큰 통찰력으로 리팩토링)가 아니라 개발 팀의 요구가 변경 될 때 발생합니다. 도메인 모델을 이해하는 데있어 획기적인 문제에 관심이 있습니다. 작은 변경을 이해하지만 모델에 큰 변경이 필요한 경우 어떻게해야합니까?

보다 명확한 도메인 모델을 얻은 후 리팩터링해야하는 자신과 다른 사람을 설득하는 효과적인 방법은 무엇입니까? 결국, 코드 구성 또는 성능을 개선하기위한 리팩토링은 유비쿼터스 언어 코드의 표현면에서 완전히 분리 될 수 있습니다. 때로는 리팩토링 할 시간이 충분하지 않은 것 같습니다.

운 좋게도 SCRUM은 리팩토링에 자신을 빌려줍니다. SCRUM의 반복적 인 특성으로 인해 작은 조각을 만들고 쉽게 변경할 수 있습니다. 그러나 시간이 지남에 따라 그 조각이 커지고 그 조각 후에 돌파구가 너무 커서 변경하기가 어려울 경우 어떻게해야합니까?

도메인 기반 디자인을 사용하는 프로젝트를 수행 한 사람이 있습니까? 그렇다면 이에 대한 통찰력을 얻는 것이 좋습니다. DDD가 제대로 달성하기가 매우 어려워 보이기 때문에 특히 성공 사례를 듣고 싶습니다.

감사!

나는 (테스트 프레임 워크의 안전망이 있거나없는) DDD를 오랫동안 좋아했습니다.

리팩토링의 전체 개념과 수명주기는 이제 새로운 설계 방법론을 사용하기 때문에 변경되지 않습니다. 상당한 시간이 걸리면 경영진으로부터 시간을 확보하기 위해 프로젝트에 비례적인 이익을 가져야합니다.

이를 수행하는 것과 관련하여 : 어떤 경우 에는 도메인 모델을 이해하는 데있어 '돌파구'로 인해 3 개월의 주요 리팩토링에 참여했습니다 . 현재 동작을 검증하기위한 테스트, 예상되는 동작 및 호출 코드의 변경을 검증하기위한 테스트가 필요했습니다. 그러나 그 이점은 상당했으며 기업은 이전에해야했지만 할 수 없었던 일을 더 많이 할 수있었습니다. 본질적으로 리팩토링은 본질적으로 '기능'이었습니다.

도메인 기반 디자인의 리팩토링은 "좋은"리 팩터가 아니라 필요에 의한 것입니다. 잘못된 도메인 모델을 식별하자마자 코드 / 시스템이 실제 문제를 나타내는 것은 아닙니다.

예를 들어, 우리는 최근에 합리적인 도메인 복잡성의 적용을 위해 노력했습니다. 청구 / 계약 시스템이었으며 새로운 유형의 요율을 도입했습니다. 우리는 정확한 2 주 스크럼 민첩한 프로세스를 사용하고있었습니다.

처음에 우리는이 모델에서 2 개의 요율이 완전히 분리되어 있고 계약을 제외하고는 아무런 관계가 없음을 확인했습니다. 그러나 우리가 더 많은 이야기를 마쳤을 때, 우리는 그것들이 실제로 동일하다는 것을 깨달았습니다. 이것은 첫 번째 경고 신호였습니다.

스토리를 짧게 줄이려면 잘못된 모델로 스토리의 90 %를 완료 할 수 있었지만 코드의 모든 부분에서 새로운 Rate를 오래된 것으로 랩핑하고 /하거나 언제 어디서나 newRate else oldRate를 만드는 경우. 우리는 속담 brickwall에 대하여 우리의 머리를 두드리고 있었다. 우리는 프로젝트의이 부분을 반쯤 밟았고, 잘못된 도메인 모델로 완료 시간이 기하 급수적이거나 실행 불가능하다는 것을 알고있었습니다. 그래서 우리는 총알을 깨고 이야기를 8 개의 다른 이야기로 나누고 도메인 모델을 리팩터링합니다.

우리가 프로젝트를 완료했을 때, 우리는 그것이 옳은 일이라는 것을 가늠에서 알았으며, 그것을 올바르게하기 위해 할 수있는 유일한 일이었습니다.

시간이 걸렸습니까? 예,하지만 그렇게하지 않으면 더 많은 시간이 걸렸을 것입니다. DDD가 제대로 되었습니까? 재밌게도 우리는 당시 DDD에 대해 알지 못했지만 Eric Evans의 DDD 워크숍에 참석하자마자 저와 제 동료들이 할 수있는 길은 없습니다. DDD를 알고 있다면 훨씬 빨리 리 팩터를 선택하여 더 많은 시간을 절약했을 것입니다.

도메인 모델에 문제가있는 경우이를 수정하는 것이 중요합니다. 내 경험상 우리는 도메인 모델을 구현할 때 도메인 모델이 다른 엔티티에 연결하는 방법에 대해 조금 놓쳤다.

이 결과로 사람들은 익숙하지 않은 방식으로 모델링하는 데 익숙해 져서 모델의 다른 부분이 "작동하도록"깨뜨 렸습니다.

도메인 모델에 문제가 있음을 알게되자 가능한 빨리 변경하십시오. 리팩토링하기 전에 시간이 오래 걸리면 이제 사용자의 정신 모델이 적용되는 사용자와 관련하여 변경하기가 더 어려워집니다.

코드의 일부 부분에서는 지속적인 리팩토링이 과도합니다. 코드의 다른 부분 (DDD에서는 소위 Core Domain )이 필요합니다. 코드가 코드를 이해하는 것이 아니라는 점을 이해하는 것은 개발자에게 추가적인인지 부하 (도메인에 대한 이해와 현재 구현의 차이)를 더 어렵게 만들거나 더 어렵게 만들 것입니다.

문제는 "이 진화가 필요한가?"입니다. 핵심 영역 (비즈니스 차이를 만들고있는 영역)에서 답은 "Yes!"입니다. 그것이 비즈니스가 더 관심을 갖는 영역과 이해 관계자를 변화시킬 영역의 묘약이기 때문입니다. 이것이 바로 도메인 모델의 유연성으로 인해 최소한의 노력으로 다음 요구 사항을 구현할 수 있도록 코드를 완벽한 형태로 유지하려는 곳입니다.

그러나 모든 응용 프로그램 코드에 적용하면 비용이 많이 듭니다 . 비즈니스에 중요하지 않은 영역 ( DDD 용어에서 지원 또는 일반 하위 도메인 )은 코어 용으로 예약 된 것보다 덜 복잡한 접근법을 요구할 수 있습니다.