すえなみ氏(@a_suenami)によるSoR/SoE論とまつわる議論のまとめ
- Tanaka9230
- 1896
- 7
- 3
- 0
【満員御礼】「ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ」満員御礼となりました! a-suenamiさん、おめでとうございます!! #builderscon twitter.com/builderscon/st… pic.twitter.com/l7TDOMb70l
2019-08-30 18:09:4516:50からの1204セミナー室でのセッションはa-suenamiさんによる、「ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ」です! #builderscon #bc1204 builderscon.io/builderscon/to…
2019-08-30 16:40:00遅くなってすいませんが、昨日の資料を公開しました。 / ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ #builderscon speakerdeck.com/a_suenami/hisi…
2019-08-31 11:47:40はてなブログに投稿しました #はてなブログ Builderscon Tokyo 2019 で「ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ」というタイトルで登壇してきました #builderscon - … a-suenami.hatenablog.com/entry/2019/09/…
2019-09-01 19:12:00@a_suenami 興味深く読ませていただきました。"SoR が UI を提供することはあるのか" ですが、例えば決済サービスがクレジットカード登録や決済のUIコンポーネントを提供するような例が有りうるような気がしています。用途はSDKに近く、SoR視点で必要最低限の機能の提供にとどめるべきで、
2019-09-02 02:04:02@a_suenami またもちろんCSS等の見た目は極力分離され、外から当てられるようなつくりにする必要がありますが...。実装パターンとしては有りうる気がしていますが、自分の中でもこのパターンがなんなのかあまり言語化はできていません。
2019-09-02 02:04:06@qsona ご意見ありがとうございますー!確かにSDKの類はありそうですね。クレジットカードの他に認証基盤的なの(Open ID Connectなど)が思いつきましたが、通信内容の秘匿性が高くてSoEを経由したくないものとかはその後ろにいるSoRが自らUI提供することはありそうです。
2019-09-02 14:33:36「プラットフォーム性」。 世の中、YAGNI的価値観と、それでも抽象論理構造はあるやろという価値観が、衝突していると思うのです。前者は原理的に間違え得ないので強い。後者は危ういバランスの上でのみ成立する。このバランスを取るのは"Hard"なんですよ。 twitter.com/hatenablog/sta…
2019-09-02 21:33:20ブログを読みませんか #はてなブログ Builderscon Tokyo 2019 で「ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ」というタイトルで登壇してきました #builderscon - ass… a-suenami.hatenablog.com/entry/2019/09/…
2019-09-01 20:05:03SoEとSoRを概念として分割すると良いみたいな話をした時に、そもそもマイクロサービス的に作ってると、SoE的なサービスとSoR的なサービスはもちろん分割するわけで、その時にわざわざSoE / SoRを意識する必要があるのかどうか、もしくはSoE / SoRは実は何かを計る尺度と考えるべきなのか、その答文字数
2019-09-03 17:05:29世の中にはマイクロサービスの皮をかぶった分断されたモノリスがあるので、そういう意味で有用かなーとか twitter.com/cero_t/status/…
2019-09-03 17:13:47SoEやSoRをシステムアクターやリリースサイクルで分類しようとするの、そんな単純なシステムばかりじゃないので、テーブルをマスタ/トランザクションどっちか?って議論と同じく不毛な結末が見える。 「失敗を前提とする(失敗することをプロセスの一部として組み入れる)か否か」で分類するようにしたい
2019-09-03 17:20:30境界をどう定めるかっていう話と、境界を見出したあとにどう整理・分類するかって話は別であって、DDD本だと責務のレイヤーだし、分散システムだとSoR/SoEみたいなアレ
2019-09-04 13:34:14すえなみさんのSoR/SoEのおはなし、分析としてはたいへん面白かっしDCIの1パターンにも見えるのですが、一方でもやっとしたところもあって、たぶんSoR/SoEに物理的な表現与えてしまうと本来モデリングで解決できる問題もこの構造の中で考えてしまうからかなと思いました。 speakerdeck.com/a_suenami/hisi…
2019-09-04 14:19:44でもやっぱりドメインモデルとプレゼンテーションモデル(CQRSでいうとライトモデルとリードモデル)の変換を誰がやるかってところだと思うのよな
2019-09-04 14:39:51@a_suenami CQRSのSは、Segragation(隔離)。 分類とはだいぶニュアンスが違う。 分類だと、どちらかといえば、とか、どちらともいえない、みたいな曖昧さが出てくる。 隔離は厳密に、あっちかこっちかを追求するイメージがある。
2019-09-04 14:42:37@masuda220 そうすると、Segragationのためには何らかの明確な基準が必要(曖昧だと隔離できないので)で、CQRSの場合はそれが副作用の有無って感じで、より実装テクニックに近い的な印象になりますね。
2019-09-04 14:45:53@a_suenami CQRSは概念的なモデルというより、実装のスタイルの一つかなあ。 個人的には隔離は選択肢の一つであって、常に目指すべき設計原則ではないな、と思っています。
2019-09-04 14:58:24「鶏と卵はどっちが先か」「鶏肉を売りたい人にとっては鶏が先で卵は仕入れ対象だし、卵を売りたい人にとっては逆だし、両者のバランスをとりたいんだったらその人向けのモデルがあるはずだよね」という話をしました。 #dddcj
2019-09-06 00:40:42@j5ik2o @pickles_imouto 現実世界で相互依存のように見えてもコンテキストを絞れば単方向依存にできるし、本当に相互依存なら仲裁者のためのコンテキストが必要だよねって話でした! お肉食べましょう!!
2019-09-06 09:18:01@haradakiro @j5ik2o @pickles_imouto バロットのことは考えてませんでしたね… モデリング奥が深いですね…
2019-09-06 09:43:04昨日の二次会で興味深かったのはエンジニアが「データ同期」とかっていう言葉を使ったときにそれってモデルで表明したいよねって意見といやいやそれデータストアの関心事でしょっていう意見があったことで、僕は後者の立場なんだけどまあ確かにモデルの中に入れたい気持ちもわかる。 #dddcj
2019-09-06 09:44:48