#presentation Date : 2019/12/11 [https://www.youtube.com/watch?v=VjtMt689ql8](https://www.youtube.com/watch?v=VjtMt689ql8) # TL;DR [https://github.com/ddd-crew/ddd-starter-modelling-process#decompose](https://github.com/ddd-crew/ddd-starter-modelling-process#decompose) で紹介されている [Context Maps](https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps) の発表だと思われる # Summary - Context Map とは相互に依存するサブシステムやモジュールの関係性を分析するためのプラクティス集 - それぞれの形態は、以下のチームの形に反映されたプラクティスになってる -  -  - コンウェイの法則的にも上に行けばいくほど依存している状態で下の方が独立性が高い - Context Map のいいところは、これらの段階的な状態を分析することに長けているということ - 例えば少なくともどこかにはSharedになってしまうようなモジュールやサービスが存在してしまう - この時に他のモジュールなどはどういった関係を持つかということが大事 ### Shared Kernel  - アーティファクトを2つのチームで共有している状態 - 積極的には採用したくない 採用するとしたら、2つの関係を構築できるか考える - Partnership - ２つのチームは依存関係にあることは明らかなので2つのチームは協力しないといけない -  - Customer/Supplier - 2つのチームは協力せずに Up Stream Down Stream の関係にある - 力関係を持ってる -  ### Big Ball Of Mud  - 採用するとしたら、というかこれは Big Ball Of Mud と共存するならというイメージ - Anticorruption Layer -  - Big Ball Of Mud はそのままにしておくと他のシステムも腐ってしまうので、腐敗帽子層を設ける この辺から独立性の高い関係の話 ### Open/Host Service  - [[Team Topologies]] の Complex SubSystem Team の APIでの会話に近い気がする - Conformist -  - Open/Host Service との組み合わせで Down Stream 側のプラクティス - Down Stram 側が完全に Upper Stream に依存して従うパターン - これは密結合しているので通常は良くないパターンであるが、強制力を働かせたいときには有効になる ### Sparate Ways  - Integrationするのはあとにして独立性を高める - 結合せずに、例えばDBを完全にコピーするなどMVPで作りたいときなどに有効になる ### Published Language  - 一般に理解された言語を使ってやりとりをするパターン - Well Degined Interface が必須になる - 委員会かなにかなどによって決まった共通言語を使う ## 感想 - どのプラクティスも見たことがあるようなものに名前がついてるだけではあったが一般に悪いと言われる状態にも名前をつけてどこが依存してしまっててクリティカルなのかを共通認識を持つのは大事に思えた - またSharedみたいなものはどうせできてしまうのでそんな中で本当にそのSharedのようなものはCoreドメインでUp Stream側にいてワークするようになっているのかというのも重要な考える要素だなと思った