「青銀行の勘定系をFirebase前提で構築できるか？」 - たなかこういちの開発ノート
Firebaseについて、事前知識 Firebaseとは、以下のような機能群を「Serverless」の文脈でバンドルしたものである。「Serverless」として、これらの統合管理コンソールの出来栄えが秀逸。 - Firestore ... Document-oriented KVS - Cloud Functions ... AWSのLambda - Cloud Storage ... AWSのS3 - Hosting ... Web Assetsのデプロイ先の提供、CDN展開サポート - Authentication ... ユーザー管理・統合認証サービスの提供 - Cloud Messaging ... iOS/Android/Web(JS)クライアントアプリへの統合プッシュ通知サービス - その他 いうまでもなく「Serverless」とは「サーバー運用・管理レス」の意味。まさに
J. Coplien氏による「Lean Architecture / DCI Evening」に参加してきました - たなかこういちの開発ノート
J. Coplien氏、および奥様のGertrud Bjørnvig氏による、こちらの講演に参加してきました。PHPメンターズの久保氏、杉本氏他の皆様は、以前よりCoplien氏と交流（※ぃぇ、こ←れだけじゃないですが。。）があって、機会あって今回の開催に至ったとのことです。 会場は、ポート株式会社様にご提供いただきました。様々な勉強会に参加させていただいておりますが、全て主催者様、スポンサー様、そして各スタッフ様あって開催が実現されるわけで、感謝いたします。（※ポート様の入居されているビルは、TIS様、セプテーニ・オリジナル様の入居されているビルと同じでした。いつのまにか馴染みのあるビルになっていました^^ ） 濃密な3時間半でした。Coplien氏はとてもゆっくりと話していただいたので、TOEIC自己評価400台の自分にもだいぶ聞き取れました。 #dcitokyo pic.twitte
参照系と更新系の非対称性について、追補 - たなかこういちの開発ノート
以前の記事を補足、あるいは主張を一部修正するものです。 〜・〜 サブジェクト指向とは？ ある要求仕様のセットがあったとき、そこに仕様変更のライフサイクルに違いのあるサブセットが認められるならば、それらは、同一のデータ資源（＝オブジェクト）に関わることであっても、別々の“モデル”として捉えよう、というのがサブジェクト指向の一つの意図です。例えば、「受注」という同じデータ（≒管理対象）に関わることでも、「注文受付オペレーター」観点の“モデル”と「販売管理担当」観点の“モデル”とでは、要求仕様のセットが異なるし、その後の仕様変更の発生タイミングや頻度も異なるでしょう。そういった状況においては、「受注」サブドメインに関わる全ての要求を一つの集約やエンティティに全て載せてしまうと、いわゆるファット・モデルとなり、当初段階はなんとかやり遂げたとしても、その後の仕様変更の度に、当初開発段階に近い苦労を都
OOは静的構造を、関数型は動的振る舞いをモデル化するのに有用だという話 - たなかこういちの開発ノート
要約 関心対象について分析し理解しようとしたら、多かれ少なかれ「要素分解していく方法」を取るでしょう。「要素分解していく方法」とは構造を捉えることに関してのアプローチです。 構造を捉えるに当たって、OOは「要素分解していく方法」をよく支援します。構成要素はオブジェクト、構成要素間の関係はオブジェクトの関連、階層理解はencapsulationとして表すことができます。しかし、OOは動的振る舞いについては、implementationに“押し付けた”のみで、なんらの解法を提供していませんでした。 ところで、動的振る舞い＝「手続き」と漫然と捉えていましたが、「手続き」とは万能チューリングマシンに由来する処理のモデル化でした。「手続き」以外に、チューリング完全である処理のモデルが存在しました。それがλ計算であり、関数型言語の「関数」です。 処理を「手続き」＝状態の時系列的変遷と捉えている限り、モ
私的実践DDD、その２ - たなかこういちの開発ノート
（※前回からの続きです。） CQRSはモデリング上の本質的な課題への対応である CQRS（Command-Query Responsibility Segregation、コマンド・クエリ責務分離）の採用は、現代的なシステムではほぼ全て必然的にそこへ帰結すると考えた方がよいと思います。CQRSという用語は「実践ドメイン駆動設計」を読むまで知りませんでした。というよりも、参照系と更新系を分離して設計しようという話をDDDが言及しているとは知りませんでした。しかし、下記記事で書いたように、要求・要件の分析観点から、参照系業務ロジックと更新系業務ロジックは非対称に構築すべきという点はむしろモデリング上の本質的な課題だとの考えを持っていましたので、CQRSはすんなり理解できました。 ※下記記事を参照してください。 《業務プロセス、業務ロジックの理解と、フロントエンド−バックエンド間I/Fの詳細》
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
