도메인 주도 설계 4부 독서 후기 Part.1 (feat. DDD)

안녕하세요. yeTi입니다.
오늘은 도메인 주도 설계 4부를 읽고 난 느낌을 기록하려고 합니다.

4부도 내용이 많아서 작은 부분으로 나눠서 기록합니다.
오늘은 4부의 1편입니다.

14장 모델의 무결성 유지 - BOUNDED CONTEXT

2018년부터 MSA를 흉내 내면서 각 서비스 간 경계를 나누는 방법으로 BOUNDED CONTEXT를 알게 됐습니다.

그러나 BOUNDED CONTEXT를 단순하게 서비스 단위를 나누는 경계로 인식하니 어떻게 사용해야 좋은지 알 수 없어 어렵게 다가왔습니다.

---

에릭 에반스가 말하는 BOUNDED CONTEXT는 명료합니다.

모델 컨텍스트란 모델에서 사용된 용어를 특정한 의미로 의사소통하기 위한 조건의 집합이다. - p.362

동일한 모델이라도 맥락에 따라 내포하는 의미와 쓰임새가 다를 수 있으니 소통하는 맥락을 경계로 모델을 구성하고 이를 기반으로 소통하자는 것입니다.

이렇게 의미를 안 이후 다시 보니, BOUNDED CONTEXT의 개념을 기술적으로 바라보고 MSA의 각 서비스 경계를 나누는 기준으로 삼는 것은 부적절하다고 느껴졌습니다.

그리고 한 팀으로 협업을 하면서 상호 간에 같은 용어를 보지만 다른 쓰임새로 생각하고 있다면 서로 다른 BOUNDED CONTEXT를 가진다는 것을 알게 되었습니다.

CONTINUOUS INTEGRATION

CI(CONTINUOUS INTEGRATION) 라는 단어를 보니 Devops 에서 말하는 소스 코드의 지속적인 통합이 떠올랐습니다.

더하여 에릭 에반스는 보다 폭넓은 수준의 CI(CONTINUOUS INTEGRATION) 를 말합니다.

이따금 다른 사람이 모델링 한 객체나 상호작용의 의도를 완전히 이해하지 못한 채로 객체를 수정해 원래의 목적으로 사용할 수 없게 만들 때가 있다. 간혹 다루고 있는 개념이 이미 모델의 다른 부분에 포함돼 있다는 사실을 알지 못해서 동일한 개념과 행위를 (부정확하게) 중복시킬 때가 있다. 때로는 다른 표현 방식을 알고 있지만 기존에 정상적으로 수행되고 있던 기능에 오류를 추가할지도 모른다는 두려움 탓에 함부로 손을 댈 수 없어 개념과 기능을 중복시키기도 한다. - p.367

현실 고증입니다.

실제로 협업을 하다보면 다른 사람이 모델링한 내용이 전파가 안되서 모르고 있거나, 의미 파악을 정확히 못하거나, 기존 기능의 오류를 추가할 수 있다는 두려움에 새로운 무언가를 만드는데 두려움을 느낍니다.

개념은 팀 구성원 간의 부단한 의사소통을 토대로 통합된다. <중략> 그와 동시에 구현 산출물은 모델 내의 균열을 조기에 드러내는 체계적인 병합/빌드/테스트 프로세스를 토대로 통합된다. - p.368

에릭 에반스는 개념의 통합을 위해서 의사소통과 산출물의 통합을 위해서 CI를 말합니다.

이어지는 생각으로 XP 에서 동일하게 의사소통의 가치에 대해서 말하고 함께 앉기, 전체 팀, 정보를 제공하는 작업 공간, 짝 프로그래밍과 같이 의사 소통의 가치를 달성할 수 있는 실천 방법들을 제안합니다.

그리고 XP에서도 지속적 통합을 얘기함에 따라 구현물의 통합에 대해서 동일한 관점을 말합니다.

결국 다수의 사람이 협업하는데 있어서 의사 소통을 통해 생각 혹은 맥락 혹은 지식을 일치하는 것이 BOUNDED CONTEXT 내에서 모델을 통합하는데 중요한 요소이며 구현물은 자동화 프로세스를 통해 지속적으로 자주 통합해야 합니다.

CONTEXT MAP

CONTEXT MAP 은 이전에 나온 BOUNDED CONTEXT 와 마찬가지로 2018년부터 MSA를 흉내내면서 접한 개념입니다.

당시의 지식으로는 BOUNDED CONTEXT 로 나뉘어진 각 서비스들의 관계를 표현할 수 있는 개념으로 이해를 했습니다. 당시 이해한 개념을 비유하면 서비스 수준의 관계 다이어그램으로 표현하기에 적합해 보입니다.

당시에도 표현 방식으로만 알고 쓰임새를 모른 상태로 넘어갔었는데 에릭 에반스의 설명을 접하니 납득이 갑니다.

CONTEXT MAP은 프로젝트 관리와 소프트웨어 설계 영역 사이에 걸쳐 있는 개념이다. 대개 컨텍스트의 경계는 팀 조직의 윤곽을 따라 정해진다. 긴밀하게 협력하는 사람들은 자연스럽게 모델 컨텍스트를 공유할 것이다. 다른 팀에 속하거나 같은 팀에 속하더라도 서로 의사소통하지 않는 사람들은 다른 컨텍스트로 분리될 것이다. - p.370-371

에릭 에반스가 다시 한번 언급하지만 BOUNDED CONTEXT 는 의사소통의 군집을 표현한 것입니다.

의사소통이 긴밀할수록 언어를 사용한 개념의 일치가 일어나기 때문에 같은 맥락내에서 모델을 이해할 수 있습니다.

의사소통을 위해 컨텍스트 간의 번역에 대한 윤곽을 명확하게 표현하고 컨텍스트 간에 공유해야 하는 정보를 강조함으로써 모델과 모델이 만나는 경계 지점을 서술하라. - p.371

CONTEXT MAP은 BOUNDED CONTEXT 로 나뉘어진 맥락간에 소통하기 위한 번역기인 것입니다.

실무를 하다보면 서로 다른 생각을 가지고 있다는 것을 발견할 때가 있습니다. 이 때 생각을 맞춰 하나의 모델로 나아갈 것이냐 각자 모델을 가지도록 분리할 것이냐를 판단할 수 있습니다. 이 때 긴밀한 의사소통의 범위를 어디까지 할 것인가를 판단할 수 있는 기준으로 삼을 수 있습니다.

일상적으로 의사소통하여 맥락이 공유되는 구성원이라면 모델을 하나로 맞춰 동일한 BOUNDED CONTEXT 를 가지는 것이 좋고, 의사소통의 맥락을 유지하기 힘든 구성원이라면 각자 BOUNDED CONTEXT 를 가지면서 균열을 CONTEXT MAP 으로 표현하는 것이 좋습니다.

현실적으로 보면 BOUNDED CONTEXT 의 단위는 대게 팀이나 서비스 단위가 될 것 같다는 생각이 듭니다.

SHARED KERNEL

잠시 CONTINUOUS INTEGRATION 으로 넘어가 보겠습니다.

개념은 팀 구성원 간의 부단한 의사소통을 토대로 통합된다. <중략> 그와 동시에 구현 산출물은 모델 내의 균열을 조기에 드러내는 체계적인 병합/빌드/테스트 프로세스를 토대로 통합된다. - p.368

개념 및 구현 산출물을 통합하라고 말합니다.

이후에 BOUNDED CONTEXT 와 CONTEXT MAP 을 얘기하면서 의사소통의 맥락으로 경계를 설정하고 번역을 통해 다른 맥락의 개념과 연결하라고 말합니다.

이제 SHARED KERNEL 을 보겠습니다.

기능 통합에 한계가 있는 경우 CONTINUOUS INTEGRATION에 따르는 비용이 너무 높다고 판단할 수 있다. 특히 팀 내에 지속적인 통합을 유지할 수 있는 기술이나 정치적인 조직이 갖춰져 있지 않거나, 단일 팀의 규모가 너무 크고 비대한 경우 이런 문제가 발생할 가능성이 높다. 따라서 개별적인 BOUNDED CONTEXT가 정의되고 이에 따라 다수의 팀이 구성될 수도 있다. - p.381

팀 내에 지속적인 통합을 위한 비용이 높다고 판단될 경우 다수의 팀이 구성될 수 있는데, 이럴 때 번역을 위한 비용이 높다면 공유 개념을 만들어 비용을 효율적으로 관리할 수 있다고 말합니다.

그런데 이상한 부분이 느껴졌습니다.

실무에서 작은 규모의 팀인데도 불구하고 CONTINUOUS INTEGRATION 을 하는 경우가 없었던 것입니다.

구현 산출물은 자동화 툴의 지원을 받아 일정 부분 달성한다고 하더라도 개념적인 통합을 달성하고자 하는 팀은 만난 적이 없습니다.

다들 할 일이 많아 바쁘기 때문에 부가적인 활동을 할 수 없다는 말들을 합니다.

지금 속해있는 팀도 빡빡한 일정에 신규 기능을 만들고 버그 수정을 하느라 개개인의 구성원이 만들어낸 개념들이 공유되지 않아 중복과 독창성이 난무합니다.

CONTINUOUS INTEGRATION 부터 숙제라는 생각이 듭니다.

고객/공급자 개발 팀

관계는 고객과 공급자 간의 관계여야 하며, 이는 고객의 요구사항이 가장 중요하다는 것을 의미한다. <중략> 이 상황은 하류 팀이 상류 팀에 필요한 사항을 부탁해야만 하는 초라한 동반자(poor-cousin) 관계와는 대조적이다. - p.385

팀 간에 업무를 하다 보면 의존성이 생길 때가 있습니다.

의존성이란 특정 팀이 다른 팀의 지원을 받아야 한다는 것을 의미하는데요.

애매하게도 지원이라는 것이 상황에 따라 갑/을 관계가 바뀔 수 있다는 것이 이번 장에서 느껴졌습니다.

비공식적으로 타 팀의 데이터가 필요해서 요청할 경우 공급 팀은 업무 외의 시간과 비용을 사용하는 것이기 때문에 지원의 적극성이 낮아질 수 있습니다.

이를 에릭 에반스는 초라한 동반자(poor-cousin) 관계로 표현했는데, 공급 팀이 갑이 되는 상황을 묘사했습니다.

이럴 때 공식적인 지원 채널을 만들어 고객/공급자 관계로 만들면 지원을 받는 고객은 보다 적극적인 지원을 받을 수 있어 안정적으로 서비스를 개선해 나갈 수 있게 되고 공급 팀은 일정이나 비용의 대가를 받기 때문에 보다 적극적으로 지원을 할 수 있게 됩니다.

간혹 실무에서 열정 페이나 선의로 시작한 업무가 시간이 지남에 따라 규모가 커질 때 발생하는 현상인데

이럴 때는 공식적으로 지원 채널을 만들어 고객이나 공급자 모두에게 지원과 책임을 가지도록 해야 합니다.

ANTICORRUPTION LAYER

클라이언트 고유의 도메인 모델 측면에서 기능을 제공할 수 있는 격리 계층을 만들어라. 격리 계층은 기존에 이미 존재하는 인터페이스를 거쳐 다른 시스템과 통신하므로 다른 시스템을 거의 수정하지 않아도 된다. 해당 계층에서는 내부적으로 필요에 따라 두 모델을 상대로 양방향으로 번역을 수행한다. - p.392

앞서 SHARED KERNEL이나 CUSTOMER/SUPPLIER DEVELOPMENT TEAM, CONFORMIST 패턴을 살펴봤습니다.

모두 다른 BOUNDED CONTEXT 간의 통합에 대해서 얘기하는데 ANTICORRUPTION LAYER 패턴은 어떤 차이가 있을까요?

앞서 세 가지 패턴은 효율적인 통합을 위한 아이디어로 볼 수 있지만 ANTICORRUPTION LAYER 는 통합의 효율보다 각 모델의 안정성에 중심을 둡니다.

보통 우리는 시스템을 다른 누군가가 작성한 것으로 생각하기 때문에 시스템에 대한 이해가 부족하고 시스템에 대한 통제력이 거의 없다. <중략> 여러 하위 시스템이 서로 다른 모델을 기반으로 한다면 여러분이 직접 설계한 두 하위 시스템을 ANTICORRUPTION LAYER로 연결하는 것이 타당한 상황도 있다. 이 경우 여러분은 양측을 완전히 통제할 수 있을 테고 단순한 번역 계층을 사용해도 된다. - p.396

우리가 개발 활동을 하면서 설계를 하고 테스트를 하는 이유는 시스템의 예측 가능성을 높여 통제력을 가지기 위해서 입니다.

하지만 다른 시스템의 경우 시스템의 이해가 거의 없기 때문에 의미를 온전하게 이해하여 변화를 만들어가기에는 위험이 동반됩니다.

이 때, 양방향 번역 계층을 만들어 새로운 모델과 기존 모델을 유지하면서 통합을 달성할 수 있습니다.

모든 통합에는 비용이 수반되기 마련이다. 통합은 매우 가치 있는 것일 수도 있지만 통합에는 언제나 비용이 많이 든다. 우리는 통합이 정말로 필요한 것인지 확인해보는 과정을 거쳐야 한다.... - p.398

에릭 에반스는 마지막에 근본을 바라보는 말을 던집니다.

결국 비용의 문제인데 해당 비용을 사용할 만큼 가치있는 일인지 항상 의문을 제시해야한다는 생각이 듭니다.

이어서 켄트 벡이 말했던 내 돈이라면 어떻게 할까 운동 이 떠오릅니다.

PUBLISHED LANGUAGE

서비스를 공유하면서 언어도 공표해야하는 이유는 오해를 줄이기 위해서 입니다.

언어를 공표함으로써 전하고자 하는 바는 단지 그 언어를 사용하는 데 관심이 있는 사람들이 언어를 손쉽게 사용할 수 있고, 해당 언어가 충분히 문서화돼 있어 각자 독립적으로 해석해도 해석한 바가 서로 호환 가능하다는 점이다. - p.404-405

해석이라는 것은 온전히 개인이나 팀의 경험내에서 자의적으로 이뤄질 수 있기 때문에 이러한 생각의 차이를 줄여 잘못된 사용으로 인해 발생하는 문제를 줄일 수 있습니다.

관련하여 에릭 에반스는 장님과 코끼리 라는 일화로 부연 설명을 합니다.

장님들이 코끼리에 관해 더 많은 정보를 공유하고 싶은 만큼 단일 BOUNDED CONTEXT를 공유해서 나타나는 가치는 늘어난다. 그러나 본질적으로 다른 모델을 통합하기란 쉽지 않은 일이다. 이러한 모델 중 어느 것도 자신의 모델을 포기하고 다른 모델을 받아들이지 않을 것이기 때문이다. 요컨대 코끼리의 꼬리를 만진 사내는 코끼리가 나무 같지 않다는 것을 알기에 이 모델은 그에게 무의미하고 아무런 소용이 없을 것이다. 언제나 다수의 모델을 통합한다는 것은 새로운 모델을 만들어내는 것을 의미한다. - p.409

우리가 같은 대상을 경험하더라도 경험의 측면에 따라 느끼는 부분이 다르고 느끼는 부분의 차이가 다른 개념을 만들어낸다는 것의 좋은 예제로 보입니다.

특히 재밌는 부분은 이러한 개념의 차이를 인정하고 통합한다는 것이 어려운 일이라는 것입니다.

따라서 다수의 모델을 통합한다는 것은 새로운 모델을 만들어내는 것과 같다고 에릭 에반스는 말합니다.

그리고 개념의 차이를 인정하기 힘든 이유를 설명합니다.

두 모델이 동일한 부분을 서로 다른 방식으로 바라볼 경우 문제는 더 까다로워진다. 두 사내가 코끼리의 몸통을 만졌는데, 한 사내는 그것을 뱀으로 묘사하고 다른 사내는 소방호스로 묘사한다면 문제가 더 어려워졌을 것이다. 다른 이의 설명은 본인의 경험과 일치하지 않으므로 누구도 다른 이의 모델을 받아들일 수가 없다. - p.410

경험의 차이에 따른 인정이 힘든 부분입니다.

일상 대화에서도 내 경험내에서는 없던 현상을 상대방이 말하면 쉽게 동의하기 힘든 이치와 같은 맥락으로 보입니다.

하물며 일상의 대화에서 조차 경험의 차이를 인정하기 힘든데 업무 도메인이 섞이면 전문성이라는 자긍심이 더 강하게 작용하기 때문에 차이를 인정하기가 더 힘들지 않을까 싶습니다.

마지막으로 에릭 에반스는 문제 해결을 위한 기본 자세를 말합니다.

다수의 서로 대립되는 도메인 모델을 인식하는 것이야말로 현실을 직시하는 것이다. 각 모델이 적용되는 컨텍스트를 명확하게 정의하는 식으로 각 모델의 무결성을 유지하면서도 두 모델 사이에서 여러분이 만들고자 특정한 인터페이스가 의미하는 바를 명확하게 확인할 수 있다. 장님이 코끼리의 전체적인 모습을 확인할 길은 없지만 자신의 인식이 불완전하다는 점만 인정해도 문제를 해결할 기미가 보일 것이다. - p.411

차이를 가지는 것은 현실을 직시하는 것인데 문제를 해결하려면 자신의 인식이 불완전하다는 점을 인정하는 것에서 출발한다는 것입니다.

저는 지금 도메인이 주도하는 설계를 알아가는 단계에서 전략적으로 설계하는 방법을 알아가고 있는데 서로 다른 BOUNDED CONTEXT 를 어떻게 통합할 것인지를 읽는 중이었습니다.

그런데 사람의 경험내에서 가지는 개념의 차이에 따른 오해와 이를 극복하기 위한 자세를 말하는 것이 신기하게 다가왔습니다.

역시 개발의 중심에는 사람이 있다는 켄트 벡의 XP가 떠오릅니다.

모델의 컨텍스트 전략

모델의 무결성을 유지함에 있어서 모델의 컨텍스트나 관련된 팀에 따라 전략을 설정할 필요가 있습니다.

전략에 따른 부수 효과는 팀의 의사소통 능력과 신규 모델의 자유도가 반비례 관계로 영향을 미친다는 것입니다.

시스템이 가지고 있는 경계에 따라. 혹은 팀의 경계에 따라 BOUNDED CONTEXT 가 존재하고 각 BOUNDED CONTEXT 경계를 따라 CONTEXT MAP 을 유지해야 팀간 혹은 시스템간 의사소통을 원할하게 유지할 수 있습니다.

그러나 간혹 시스템 통합이 비효율적인 방향으로 이뤄질 수 있는데, 이는 경영이나 기업을 운영하면서 만들어지는 인간관계에 따라 결정되는 경우들이 있기 때문입니다.

실제로 팀 간의 정치적 관계로 말미암아 시스템의 통합 방식이 결정될 때가 많다. 기술적으로 이로운 단일화가 보고체계 탓에 불가능해질 수도 있다. 경영진에서 현실적이지 못한 합병을 지시할지도 모른다. - p.412

그럼에도 불구하고 우리는 발생하는 비용을 평가 및 전달하고, 이를 완화할 조치를 취할수는 있습니다.

그리고 새로운 시스템을 만들면서 기존 모델의 확장이나 새로운 개념의 추가 그리고 배치까지 다양한 관점에서 모델의 통합 여부를 판단해야 합니다.

일반적인 관점에서 보면 협업과 의사소통에 드는 추가적인 노력과 자연스러운 기능 통합이 주는 이점 사이에서 타협점을 따져볼 것이다. 즉, 좀더 독립적인 활동과 순조로운 의사소통을 맞바꾸는 셈이다. 좀더 야심 찬 단일화를 위해서는 관련 하위 시스템의 설계를 통제할 필요가 있다. - p.418

그럴 때는 앞서 언급했듯이 독립적인 활동과 순조로운 의사소통 사이에서 적절한 의사결정이 필요합니다.

변형

모델의 무결성을 유지하기 위한 개념을 잡고 패턴을 제시하며 전략을 알아가는 과정에 있습니다.

마지막으로 에릭 에반스는 변화에 대해서 이야기합니다.

우리가 BOUNDED CONTEXT 를 기준으로 경계를 나눠 업무를 진행하는 과정에서 BOUNDED CONTEXT 간 통합을 해야 할 필요가 있을 수 있습니다.

이럴 때는 두 BOUNDED CONTEXT 를 한번에 통합하려고 하지 말고 중요도가 낮지만 중복되는 것을 선별하여 공유 도메인을 만들면서 시작하는 것이 좋습니다.

궁극적인 목표가 CONTINUOUS INTEGRATION을 토대로 단 하나의 CONTEXT로 완벽하게 병합하는 것이더라도 우선은 SHARED KERNEL로 옮기는 것으로 시작한다. - p.420

어느 정도 공유 도메인이 만들어지기 시작하면 두 BOUNDED CONTEXT 의 전체적인 통합에 욕심을 낼 수도 있습니다.

그러나 서로 다른 BOUNDED CONTEXT 의 통합은 구현체의 통합뿐 아니라 개념의 통합까지 달성해야하기 때문에 주기적이고 지속적으로 CONTINUOUS INTEGRATION 을 해야합니다.

SHARED KERNEL이 확장되는 중이라면 두 BOUNDED CONTEXT를 완전히 단일화했을 때 얻을 수 있는 이점에 현혹될지도 모른다. 이것은 단순히 모델의 차이점을 해소하는 것과 관련된 문제가 아니다. 팀의 구조, 궁극적으로는 사람들이 사용하는 언어가 바뀔 것이다. - p.422

---

만일 레거시 시스템을 폐기해야한다면 단계적으로 진행해야합니다.

이는 켄트 벡의 XP에서도 동일한 의미를 전합니다.

패키지 제품을 이용해 현재 기능을 다시 구현한 다음, 어느 일요일 밤을 기점으로 단 한 번에 넘어가는 것이었다. 나의 즉각적인 반응은 "그 방식은 절대 먹히질 않아." 였다. - p.107, 켄트 벡 - XP, 9장 보조 실천방법

에릭 에반스 또한 단계적 폐기를 말하는데 중간에 ANTICORRUPTION LAYER 를 둬 레거시와 신규 시스템간에 번역을 수행하며 진행해야 한다고 말합니다.

레거시 시스템이 업무에 관여하는 빈도가 계속 줄어들어 오랜 고난을 거쳐 마침내 빛을 보게 될 쯤이면 구형 시스템을 폐기할 수 있을 것이다. 한편, 다양한 조합으로 시스템 간의 상호종속성이 늘어나거나 줄어들면 ANTICORRUPTION LAYER가 번갈아 줄어들거나 팽창할 것이다. - p.424

실무에서도 레거시 서비스와 신규 서비스간 번역을 위해 ANTICORRUPTION LAYER 를 사용하고 있어 실무적으로도 공감이 되는 부분입니다

---

마지막으로 지금까지 서로 다른 두 시스템간의 통합을 이야기 했지만 사용자가 늘어나는 경우도 이야기합니다.

지금까지 일련의 임시방편적인 프로토콜을 갖춘 다른 시스템과 통합해 왔는데, 접근을 원하는 시스템이 늘어나거나 상호작용이 점차 이해하기 어려워지면 유지보수 부담이 가중될 것이다. 이 경우 PUBLISHED LANGUAGE를 갖춘 시스템 간의 관계를 공식화해야 한다. - p.425

에릭 에반스가 언급한것처럼 우리 시스템을 사용하는 사용자가 많아질 경우 통합을 고려하기 보다는 언어를 공표하여 공식적으로 호스트를 오픈하는 것이 유지보수 부담을 줄일 수 있습니다.

마무리

이번 내용은 모델의 무결성 유지 를 말했습니다.

이미 책이 한 번 읽고 함께 읽기를 진행하고 후기를 쓰고자 정리한 내용을 한 번 더 보는 과정에서 신기한 느낌이 들었습니다.
이유는 결국 모델이라는 것은 개념화의 결과인데 개념이라는 것은 사람들이 사용하는 언어에 기초한다는 느낌을 받았기 때문입니다.

BOUNDED CONTEXT 를 시작으로 CONTINUOUS INTEGRATION, CONTEXT MAP 은 개념을 정의하고 공유하고 관계를 가지라는 말이고, SHARED KERNEL, 고객/공급자 개발 팀, ANTICORRUPTION LAYER, PUBLISHED LANGUAGE 는 관계를 가지는데 어떠한 방법들이 있는지 알려 줍니다.

마지막으로 모델의 컨텍스트 전략, 변형 에서 이상적인 관계를 가지기가 힘든 이유를 현실적인 상황들을 예시로 들며 설명을 해줘 적정 수준에서 협업을 하는 방법을 알려 줍니다.

일반적으로 설계라는 활동을 기술적으로 접근하기 쉽고 이 책에서 말하는 도메인과 모델이라는 것도 기술적으로 잘하는 법을 기대하기 쉽지만, 실제로 설계라는 활동은 비즈니스 영역과 관심 영역, 우리가 가진 의사소통 역량이나 업무 방식에 따라 다양한 형태로 나타날 수 있다는 것입니다.

개발자들이 기술적인 영역만으로 설명할 수 없기 때문에 설계나 도메인 주도라는 활동이 어렵게 느껴지는 것이라는 생각이 들었습니다.

최근 인간의 인지 능력, 개념, 말 이라는 것을 배우면서 14장인 모델의 무결성 유지를 정리하며 개발이라는 활동에 굉장히 중요한 부분을 잘 설명했다고 느꼈습니다.

지난 기록

• 도메인 주도 설계 3부 독서 후기 Part.2 (feat. DDD)
• 도메인 주도 설계 3부 독서 후기 Part.1 (feat. DDD)
• 도메인 주도 설계 2부 독서 후기 (feat. DDD)
• 도메인 주도 설계 1부 독서 후기 (feat. DDD)
• 14장 모델의 무결성 유지 - 변형
• 14장 모델의 무결성 유지 - 모델의 컨텍스트 전략
• 14장 모델의 무결성 유지 - PUBLISHED LANGUAGE
• 14장 모델의 무결성 유지 - ANTICORRUPTION LAYER
• 14장 모델의 무결성 유지 - 고객/공급자 개발 팀
• 14장 모델의 무결성 유지 - SHARED KERNEL
• 14장 모델의 무결성 유지 - CONTEXT MAP
• 14장 모델의 무결성 유지 - CONTINUOUS INTEGRATION
• 14장 모델의 무결성 유지 - BOUNDED CONTEXT