"DDD는 우익입니다!"

이 도발적인 발언(언컨퍼런스 세션을 시작하고 사람을 모으는 데 이상적임) 뒤에 Simon Chaveneau 는 DDD(Domain Driven Design)가 소프트웨어를 생산하는 조직(제품 기술)에 미치는 영향에 대한 질문을 스스로에게 묻고 싶었습니다. 이것은 Agicap의 첫 번째 비컨퍼런스에서 발생했습니다. 제품 및 기술 직원이 만나 토론하고, 배우고, 공유하고, 웃을 수 있지만 무엇보다도 일상 생활과 관련하여 높이 올라갈 수 있도록 조직되었습니다.

언컨퍼런스 동안 프로그램은 청중에 의해 수립됩니다. 아침에 초기 "마켓 플레이스" 세션에서 수행됩니다. 오늘의 첫 번째 본회의에서는 모든 사람이 스티커와 마커를 잡고 모든 사람 앞에서 세션을 발표할 수 있습니다. 그런 다음 사람들이 오늘의 프로그램에 배치합니다(이 언컨퍼런스에 대한 자세한 내용은 이 트위터 스레드 가 있습니다).

그러나 Simon이 제안한 주제와 흥미로운 세션으로 돌아가 보겠습니다.

사유재산의 지배?

Simon의 초기 피치를 요약하면 다음과 같습니다. IS의 전체 섹션이 팀에 속하는 경우(각각 하나 이상의 BC(Bounded Context)를 담당) 소프트웨어 버전의 사유 재산(BC 주위에 철조망 등)에 직면하지 않습니까? .)? 그래서 그의 도발적인 “ DDD는 우익이다! ”

그리고 부차적인 질문: “기능 팀을 기반으로 하는 조직이 더 효율적이지 않을까요? (모든 사람이 사용 사례로 가는 도중에 모든 BC에서 작업할 수 있음)”

음... 제품/기술 구성 모드에 대한 정말 흥미로운 토론이 이어졌기 때문에 이 세션이 처음에 기대했던 것보다 훨씬 더 유익한 것으로 판명되었음을 인정해야 합니다.

그러나 우리가 매우 많았던 이 세션에서 취한 경로를 자세히 설명하기보다는(확실히 다른 게시물의 맥락에서 설명하는 것이 흥미로울 것임) 주제에 대해 내가 유지하고 생각하는 것을 설명할 것입니다.

몇 가지 관찰

• 효과적인 소프트웨어는 비즈니스 과제에 부합하는 소프트웨어입니다 . 정렬이란 도메인 분야에서 올바른 용어를 차용하고 비즈니스의 핵심 개념을 정확하게 표현하고 기술적 문제로 인한 우발적 복잡성을 가능한 한 적게 소환하는 소프트웨어를 의미합니다. 이것은 여기에서 3분 안에 설명된 DDD(Domain Driven Design)의 주요 과제 중 하나입니다 .
• Conway의 법칙은 선택하지 않을 수 있는 옵션이 아닙니다.‍♂️ 중력의 인력과 같은 특정 물리 법칙처럼 작용합니다. 우리는 그것에 맞서 싸울 수 있습니다 ;-) 그러나 그것은 여전히 ​​지구상에서 유효합니다.
  Conway의 법칙은 "(넓게 정의된) 시스템을 설계하는 모든 조직은 구조가 조직의 커뮤니케이션 구조의 사본인 설계를 생산할 것"
  이라고 명시한 1967년 법률입니다 . 다른 말로 하면, 소프트웨어의 아키텍처는 필연적으로 소프트웨어 설계에 관련된 사람들의 커뮤니케이션 방식의 결과입니다. 예를 들어, 3개의 팀에서 개발한 컴파일러는 3개의 패스에서 작동하거나 3개의 개별 모듈을 가질 가능성이 높습니다.
• ICM(Inverse Conway Maneuver)을 사용하면 Conway의 법칙을 제어할 수 있다고 생각할 수 있습니다. 처음에 이러한 반대 전략은 " 팀의 효과적인 협업 능력을 제한하는 사일로를 무너뜨리는 것"을 현명하게 권장했습니다 . 그러나 수년에 걸쳐 " 목표 아키텍처에 도달하기 위해 조직을 변경하십시오 "라는 어리석은 권장 사항으로 변모했습니다 . "문화는 아침에 전략을 먹는다"를 기억하기 때문에 어리석은 일입니다. 흥미로운 스레드에서 더 많은 정보를 얻을 수 있습니다.
• Domain Driven Design은 어떤 조직도 부과하지 않습니다. 기능 장애가 있는 조직(전쟁 중이거나 서로를 무시하는 팀)의 경우를 포함하여 생존을 가능하게 하는 열쇠를 제공합니다. DDD는 팀 간의 권력 문제와 사회적 문제를 이해하는 데 도움이 됩니다. 결과적으로, 그것은 오히려 우리의 결정론에 대한 해방의 도구입니다( 따라서 제가 말하고 싶은 좌익 도구 ;-)
• 반면에 DDD는 도메인과 관련하여 가능한 한 정렬된 효율적인 소프트웨어를 설계할 수 있는 도구를 제공합니다. 그 중에는 사용을 위한 모델을 설계하고 모델을 둘러싸며 다른 컨텍스트에서 발생하는 혼란/잘못된 친구/오해로부터 보호할 것을 제안하는 제한된 컨텍스트(BC)의 개념이 있습니다.
• 더 많은 조정과 효율성을 위해 DDD는 우리의 비전과 솔루션 모델링에 정기적으로 도전할 것을 강력히 권장합니다. 그것은 또한 유레카 순간( 설계 돌파구 라고 함)에 따라 수시로 모델을 혁신하고 변경하는 것을 의미합니다 . 그렇기 때문에 제품 담당자와 함께 현장에 대한 우리의 비전을 지속적으로 개선하는 컨텍스트 맵 세션을 이곳에서 정기적으로 개최합니다.
• 개발팀은 균형이 깨지기 쉽습니다. 개발 팀이 실제로 효과적이려면 함께 생활하고 대인 관계를 유지하는 데 약 6개월이 걸립니다. 이 팀에서 한 사람을 추가하거나 제거하면 더 이상 같은 팀이 아닙니다( 동적 리팀 구성 참조 ). 효율성 측면에서 나는 주제에 따라 폭발/재분배되는 팀보다 함께 있으면서 주제를 바꾸는 팀을 선호한다. 물론 누군가가 팀이나 주제에 지쳤다면 팀을 변경할 수 있도록 모든 조치를 취해야 합니다.
• Agicap의 현재 조직과 팀은 문제의 복잡성을 고려하고 각자의 비즈니스 전문 지식을 최소한으로 활용하기 위해 하나 이상의 제한된 컨텍스트에 소속되어 있습니다. 때때로 일부 팀은 너무 큰 범위를 가질 수 있으며 바인딩된 컨텍스트를 더 잘 자르고 할당해야 합니다. 반면에 이러한 BC 분할은 비즈니스 개념과 연결된 상태로 유지되어야 합니다(DDD를 기억하십시오).
• 모두가 제한된 컨텍스트의 경계를 존중하는 한 DDD를 수행하는 조직에 기능 팀이 있는 것을 금지하는 것은 없습니다 .
• 당분간 우리는 Swarming (여러 팀의 사람들로 구성되지만 최종 아티팩트(도구, API, 라이브러리)의 책임과 소유권이 처음부터 정의되는 일종의 태스크 포스)의 실행을 매우 선호합니다. 도움이 됩니다. "좋아요, 우리는 함께 무언가를 했지만 지금은 누가 그것을 유지하겠습니까?!?"라는 증후군을 피하기 위해). swarming은 주제에 따라 적절한 사람들이 협업하도록 하는 효과 외에도 일시적으로 팀 간 대인 관계를 촉진하여 조직에 많은 사회적 자본을 제공합니다 (모든 사람이 팀으로 돌아올 때 매우 유용함).
• 우리의 현재 제품 조직은 개발 팀당 1명의 제품 관리자(PM)로 설정되어 있지만 PM이 팀보다 비즈니스 주제와 더 관련되어 있으면 흥미로울까요?

마지막으로, 우리가 개발에 가지고 있는 것보다 조직에 묘책이 더 이상 없다고 말하고 싶습니다. 지속적인 피드백, 질문 및 실험은 사용자와 관련된 소프트웨어를 효과적으로 만들기 위한 이러한 지속적인 개선 경로의 동반자입니다.

참고: 이 게시물은 지난 주(2022년 10월 14일)에 작성된 프랑스어 기사를 번역한 것입니다.

Agicap에 대해 자세히 알아보려면:

• Show me your Domain ( 현금 흐름 모니터링 및 예측 컨텍스트 맵 세션 )
• https://agicap.com/
• https://career.agicap.com/