ネットスーパーシステムの決済ステータス表現 (状態遷移) は複雑だ。 その理由は要求要件が多いことに起因しているが、多いことが悪いのではなく、それに応えなければシステムとして真の価値を発揮できないからで。逆に問題解決できなければ、著しく利便性を落としてしまうので、必須要件という位置付けにある。 前提文脈を汲み取りづらいモデリングなので、問題解決例を示すのはあまり見かけないが、自分が考えた決済ステータス定義の答えを示す。 この内容は過去にブログや登壇で話した内容の延長でもあるので、過去の内容も参考にすると良いかもしれません。 「E-Groceryにおけるカード決済処理の難しさと設計戦略」 「ネットスーパーの買い物体験を支える工夫と決済機能実現の過程」 前提条件 注文から支払い完了まで時間差がある注文後に注文内容の変更ができる品切れが発生するケースがある販売員が注文内容を変更できる0円での支払
ごきげんよう🙋♀️ツクリンクでエンジニアリングマネージャーをしているあっきー（@kuronekopunk）です。 この記事はツクリンク プロダクト部 Advent Calendar 2023 4日目の記事です。 前日はSRE泉田さんの「ECS スケジュールされたタスクが起動しなかったことを監視する」でした。 自社サービスのツクリンクは最初は自分がPHPで作っていましたが、エンジニアの参画と合わせて2014年からRuby on Railsにリプレースしています。 リプレースから10年弱経った今、とりあえずで作ったけどサービス成長で運用が辛く負債に感じる部分を紹介していきます。（2021年に書いたRails以降時のnote） メール、通知の設計管理者のアドレスをBCCに入れた0→1のサービス開発当初、「ユーザーさんに送ったメールの内容を知りたい」という動機からユーザーさん宛のメールのBCC
Speaker Deck This deck requires a password Password
「良いコード/悪いコードで学ぶ設計入門」レビュー 「良いコード/悪いコードで学ぶ設計入門」という書籍に色々と気になることが書かれていたので、今更ではありますが、特に気になる6章を中心にレビューしたいと思います。自分は著者を存じ上げませんが、この書籍を執筆中に下読みとして読んだつもりで、気になる点を列挙したいと思います。 なお、書籍のサンプルコードは Java で書かれていましたが、この記事内では Kotlin で書かせていただきます。 著者・関係者の方々の気分を害されたら申し訳ありません。 取り上げる題材の統一感 まず、6章全体で取り上げられている題材(サンプルコード)に統一感がありません。 6章で扱われている題材はざっと分けると次のようになっています。 6.1 魔法発動処理 6.1.2 生命状態判定処理 6.2 魔法種別による分岐処理 6.2.6 面積計算処理 6.2.7 魔法別コスト計
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み 大規模なソフトウェア開発においてモノリシックかマイクロサービスかというアーキテクチャの議論がありますが、近年は第3の選択肢としてモジュラモノリスが話題になっています。いったんマイクロサービス化に舵を切りながら現在はモジュラモノリスに取り組むアソビューの考え方や進め方について、VPoEの兼平大資（disc99）さんによる寄稿です。 アソビューでは、現在の事業状況にマッチしていることや過去の経緯から、モジュラモノリスを中心としたアーキテクチャを採用しています。 今回は、なぜその選択をし、どのように実現しているかを紹介します。 記事の前半では、アソビューが提供する事業や、アーキテクチャに対する考え方、開発組織の歩みなどを説明します。 中盤以降は、アソビューにおけるモジュラモノリスへの取
河野 岳史（スパークスシステムズ ジャパン株式会社） はじめに この記事では、最近利用者が増えていると感じているシステムモデリング言語SysMLについて、ツールベンダーという立場・観点で最近の状況をお伝えします。 SysMLとは？ SysMLとは、OMG（Object Management Group）によって公開されている、システムをモデリングするための記述言語（Modeling Language）です。 OMGはSysMLだけでなく、ソフトウェアの設計を視覚的に表現することを目的に定義されたUML（Unified Modeling Language）や業務の流れを可視化するBPMN(Business Process Modeling Notation)など、さまざまな記法・記述言語の定義や普及に努める国際的な団体です。SysMLの現在のバージョンは1.5で、次期メジャーバージョンアップ
皆川 誠 本記事は、2008年11月17日公開のものを再掲載しています。 はじめに この連載では、コンサルティングでのモデル・レビューの場、教育講座実施中、各種の勉強会などの際に良く観察される、UML表記法やモデリングに関する典型的な誤解/勘違いをとりあげて解説を加えていきます。これによって、より正確なモデルの読み書き、効果的なモデル作成など、モデリング・スキルの向上を狙います。また、必要に応じて「あまり広く知られていないが、知っていると便利」なモデル要素や表記法についても随時紹介していこうと思います。 連載第1回のテーマは「コンポジション(Composition)」です。 コンポジションはクラス図でのクラス・アイコン間に引かれる関連線の一種で、インスタンス間の強い集約関係(全体-部分関係)を表現します(図1)。ここでは、コンポジションに関して良く観察される誤解や勘違いのいくつかを紹介して
TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日本でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守（あるいは鹿鳴館精神）ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ
Noriyuki OHKAWA @notogawa データ型Aとその操作を定義しているモジュールX.Y.Aてよく作ると思うけど，型Bと型Aの間の変換操作をＸ.Y.A内から露出させるときにfromA/toAはやめてくれー．toB/fromBにして欲しい．import X.Y.A as AでA.toB/A.fromBだから． 2016-11-18 09:52:37 Noriyuki OHKAWA @notogawa データ型Aとその操作を定義しているモジュールX.Y.Aてよく作ると思うけど，型Bと型Aの間の変換操作をＸ.Y.A内から露出させるときにfromA/toAはやめてくれー．toB/fromBにして欲しい．import X.Y.A as AでA.toB/A.fromBだから． 2016-11-18 09:52:37
解決策1 集約をマージするタイプのアイデア 解決策2 一時的な整合性の破綻を受け入れ結果整合性を使うタイプのアイデア A. 組織へ無効状態で追加後、有効化するアイデア A.i 連続的に追加・有効化を行うアイデア A.ii 追加後、有効化を別スレッドやイベント駆動で行うアイデア B. 組織に所属するユーザー一覧というドメインオブジェクトをアイデア B.i ユーザー一覧を組織集約に持たせるアイデア B.ii ユーザー一覧を独立した集約にするアイデア C. イベント駆動アーキテクチャの長期プロセス(サーガ)的なアイデア D. オーバーがNGなら逆に現在ユーザー数を先に増やすアイデア 解決策3 アンチパターンではあるが集約間の整合性維持のためトランザクション制御を用いる 解決策4 ユースケースの見直しによる再モデリングタイプのアイデア 僕の現時点での回答らしきもの 現時点での回答: 解決策2 B.
本記事はドメイン駆動設計 Advent Calendar 2018 - Qiitaの3日目の記事です。 2日目は、grimroseさんのぐるぐるDDDで気をつけてることでした。 4日目は、s_edwardさんのMicroservices と DDDです。 Table of Contents Table of Contents 以下の記事を読むにあたり前提となる知識 問題 サービス詳細 ユビキタス言語 重要なビジネスルール モデリング 上の何が問題？ 解決策 解決策1 集約をマージする 解決策2 一時的な整合性の破綻を受け入れ結果整合性を使う 解決策3 アンチパターンではあるが集約間の整合性維持のためトランザクション制御を用いる 解決策4 ユースケースの見直しによる再モデリング まとめ とりあえず今どうやっているか 最終的にどうするべきだと考えているか(2018/12/01時点) ソリューシ
簡単まとめシリーズ 今回は 集約とトランザクション境界 について、 自分のわからないところを調べたので、メモとして残しておきます。 集約 集約の説明を『ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本』 から拝借すると、 「データを変更するための単位として扱われるオブジェクトの集まりを集約といいます」とのこと。 ↓ もうすこし具体的に言うと DDDではエンティティと値オブジェクトというものがありますが、 値オブジェクトを直接触らず、 エンティティ経由でしか変更しないようにするというものですね。 このような制限をかけることで、 ひとまとまりにされたオブジェクト間で維持されるべき不変条件を守ることができます。 トランザクション境界 基本的な考えとしては、集約ごとにトランザクションを貼ります。 ↑この基本を守るためにも、理想としては正しいモデリングにより、 正しいトランザクシ
本エントリは、xUnit Test Patterns: Refactoring Test Codeという書籍の「Chapter5 Principles of Test Automation」の内容をベースに、12個のユニットテスト原則についてまとめていきます。この書籍は、2007年に販売されたものですが、今でも十分役に立つユニットテストに関する原則を伝えています。 ウェブでは、次のURLでも内容を見ることができます。 自動ユニットテストの原則 ここで紹介されるものは、ユニットテストで確認したい quality のリストです。ですので、直接適用する「パターン」ではありません。 「何をやるか」よりも「なぜやるのか」という観点においてまとめられています。 本エントリでは、xUnit Test Patterns: Refactoring Test Codeで紹介されている12個の原則をベースに、ほ
DHHの Dependency injection is not a virtue(2013) という記事は有名ですが、ちゃんとした日本語訳が意外とないようなので、書き出してみて思ったことを要約してみた。[1] Rubyのエンジニアの中には、何も考えずに他のモデルのnewを書いてる人の割合が多いという（コードレビュー時のヒアリングによる）体感があり、また8年前の記事なので経験の浅い人は読んだことがない人もいると思う。該当する方は是非読んでほしい。 全部読む時間が無い人は要約へ. 原文と訳文 In languages less open than Ruby, hard-coded class references can make testing tough. If your Java code has Date date = new Date(); buried in its guts,
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。
2013-06-24 2012年4月23日にテキサスの Austin で行われた RailsConf 2012 での Rich Hickey (@richhickey) さんによる基調講演、Simplicity Matters を書き起こして翻訳しました。 Rich Hickey さんは Clojure や Datomic の作者です。 この翻訳は Creative Commons Attribution ShareAlike 3.0 ライセンスに基いて公開します。 Rich Hickey 講演 e.e d3si9n 訳 談: こんにちは。ご招待いただきありがとうございます。 聞く所によると RailsConf はいつもコミュニティーからかなり外れた人を選ぶらしく、今回は僕ということになりました。 僕の電話ボックスは外に駐車してあります。(会場、笑) だけど、今日は言語の壁を越える話題を持
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
