keisuke_yamaneのブックマーク / 2021年6月28日

keisuke_yamane id:keisuke_yamane

2021年6月28日のブックマーク (3件)

Appleを超えるブランド Peloton / 現代の聖職者はエアロバイクに乗る
https://www.racked.com/2018/8/6/17657516/peloton-at-home-fitness-flywheel-classpass-rumble昨年から、今一番クールで面白い会社はPelotonと言い続けています。再定義された次世代型のブランディング、他に類を見ないビジネスモデル、全米ぶっちぎり1位のリアル店舗のパフォーマンス、ハードから物流、コンテンツを含む垂直統合、カルチャー、宗教性など多様な面で示唆を与えてくれるスタートアップです。昨年秋に担当したグロービスの「デザイン経営」の授業でも1コマの大部分を使って解説・ディスカッションをさせてもらいました。これはPeloton CEO John Foleyのプレゼンテーション。これからのコンシューマプロダクトのブランドが果たすべき役割について、深い洞察とデータを元に語られています。他の業界にも非常に
keisuke_yamane 2021/06/28
marketing

futurework

organization
リンク
CQRS実践入門 [ドメイン駆動設計] - little hands' lab
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題解決策 CQRSのメリット、デメリット実装時の注意事項部分的導入についてなぜQueryServiceの定義がUseCase層なのか整合性をどうやって担保するのかよくある誤解データソースを分ける必要があるのかイベントソーシングとの関係過去資料との繋がりもっと詳しく知りたい方は現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。参考過去記事
keisuke_yamane 2021/06/28
microservice
リンク
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。一貫性：「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なしストレージ：「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的スケーラビリティ：「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きいなので分けちゃうわけですが、コマンド側複雑なビジネスロジックが絡むので、ドメイン駆動が活躍クエリ側複雑なビジネスロジックがないので、ドメイン層はスキップ
keisuke_yamane 2021/06/28
microservice
リンク
- 2021年6月29日
- 2021年6月28日
- 2021年6月27日