NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ
https://en.wikipedia.org/wiki/Wicked_problem http://heim.ifi.uio.no/~dino/SSW-KF/L10/Conklin-DialogueMapping.pdf 1. 厄介な問題に決まった形はない。 2. 厄介な問題には終わりのルールがない。 3. 厄介な問題に対する解決策は、正解/不正解があるのではなく、良いか悪いかがある。 4. 厄介な問題に対する解決策は、すぐには検証できないし、完全に検証することもできない。 5. 厄介な問題にたいする解決策はすべて「1回きりの対処」になる。試行錯誤して学ぶ機会もないので、毎回の試行が重要だ。 6. 厄介な問題には、とりうる解決策を列挙できるものはないし、計画に組み込むことが出来るようなハッキリしたオペレーションもない。 7. 厄介な問題は皆、本質的に独自性がある。 8. 厄介な問題は皆
いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く