モデリングとアーキテクチャの知見を積み上げて基幹システムに可変性を注入する - MonotaRO Tech Blog
こんにちは。 この記事では、2024/5/22に開催された「アーキテクチャを突き詰める Online Conference」で弊社CTOの普川がお話しした内容（ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する〜モノタロウ基幹システム刷新の実践例）を、現場目線から改めてご紹介します。 なお、本稿の執筆は頼と尾髙が分担しておりまして、途中で急に文体が変わったな？と違和感を持たれることもあろうかと思われますが、ご容赦いただけますと幸いです。 本稿をさらに深掘りするイベントを10/4(金)に開催いたします。 ご興味ある方はぜひご登録ください。 https://connpass.com/event/328360/ 問題領域は関連システムの密結合点 分割を試みる 最初のモデルを手に入れる レイヤードアーキテクチャに沿って実装 レイヤードアーキテクチャのメリット モデルを洗練させ
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
ChatGPTに要件定義をお願いしたらハンパなかった | DevelopersIO
架空の営業管理システムを作ってもらう前提で、ChatGPTに要件定義をお願いしてみました。 実験として軽く試すレベルで始めてみたのですが、予想を超えるクオリティでしたので、一部始終を皆様にもご紹介します。 ChatGPTとのやりとり まず、ざっくりと必要な機能の洗い出しをお願いしてみました。 あっという間に必要な機能を網羅的にリストアップしてくれまた。私自身、SFA/CRMをいくつか触った経験がありますが、適切な内容だと思います。 中には、「データのインポート・エクスポート機能」のように、検討初期段階ではつい忘れそうな機能も含まれています。さらに頼んでもいないのにオススメの検討プロセスまで教えてくれました。気が利いてます。 機能ベースだと要件の妥当性が判断しにくく思ったので、画面ベースで要件定義してもらことにしました。 「図で教えて」とできないことをお願いしたところ、やんわり断りつつ、意図
Mackerel のフロントエンド "React化" プロジェクトを支える技術と設計 - Hatena Developer Blog
こんにちは, Mackerel 開発チーム アプリケーションエンジニアの id:susisu です. 現在 Mackerel では, Web コンソール画面の開発に使用しているフレームワークを, これまで使用してきた AngularJS から React へ移行することを中心とした, フロントエンド開発の刷新プロジェクトを行っています. このプロジェクトの立ち上げについては以前 Hatena Engineer Seminar で発表しましたが, そこでは時間の都合もあり, 技術的側面についてはあまり深く掘り下げることは出来ませんでした. ということでこの記事では, より技術的な面にフォーカスしてプロジェクトの内容をご紹介できればと思います. "React化" プロジェクトについて Mackerel の開発は 2014 年ごろから始まりましたが, フロントエンドのフレームワークとしては当初か
論理的思考の放棄 - 登 大遊＠筑波大学情報学類の SoftEther VPN 日記
僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
WEBフロントエンドにおけるソフトウェア設計の考察
https://fortee.jp/object-oriented-conference-2020/speaker/proposal/view/b06110e6-717e-4cb2-97c3-cd8d53693378 の初版スライドです 当日の発表版は https://speakerdeck.…
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
コードを書いて金を稼ぐ - kuenishi's blog
初めてまともに携わったシステムはNTT研究所で作られていたCBoCといわれるものであった。内容について詳しくは述べないが、国内では割と先進的でありながらとにかくNTTの事業会社（割と稼いでいる）で使えるものを作ろうというものであった。この時期は研究所は研究だけしていればよいというものではなく事業貢献が求められており、論文になるような研究を生み出すだけでなくそれをどうやってビジネスにするかが重要視されていたのだと思う。このとき作ったものは実際に事業会社で使われ、退職の前後には年間数万円が口座に振り込まれるようになっていた。なお収入なので税金の扱いを間違えないように。しかし特許といえばガッポガポ…というイメージだがそんなに当たることはない。わたしが携わったそのソフトウェアは確かに使われていたが、事業会社のビジネスの中核を支えていくようなものにはならなかった。ならなかったのでメンテナンスフェーズ
『Design It! ― プログラマーのためのアーキテクティング入門』 - snoozer05's blog
翻訳を担当した書籍『Design It! ― プログラマーのためのアーキテクティング入門』（オライリー・ジャパン）が11月25日に発売になります。本書は2017年にPragmatic Bookshelfより出版されたMichael Keeling著『Design It!: From Programmer to Software Architect』の全訳です。Pragmatic Bookshelfファンにはおなじみの「... It!」シリーズの一冊で、日本語で読める「... It!」シリーズとしては4冊目の書籍となります。 O'Reilly Japan - Design It! 本書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを
フロントエンドのつくりかた
フロントエンドの特定技術について語る解説は多くあれど、そもそもフロントエンドのつくりかたについて語った解説は多くないのではないでしょうか。 フロントエンドという大きな領域ですので恐れ多くもありますが、私が GUI プログラミングに携わった経験をもとにお話した内容のスライドとその補足をここでしたいと考えます。 スライド スライドのページ数は多いですが、差分がほとんどですので、それほど構える必要はないです（カーソルキーに負担がかかるという問題を除いて）。 補足解説 大きなテーマごとに補足をしていきます。 スライドで取り上げているテーマは次の４つです。 GUI アーキテクチャパターン データの同期 エラーハンドリング コンポーネント構造 「GUI アーキテクチャパターン」はいわゆる MVC や MVP といわれるものがどういったものかを解説する章です。 「データの同期」は画面と実際のデータが離れ
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
ユーザー基盤を作り直しながらRailsでのサービス層に向き合う - クックパッド開発者ブログ
こんにちは。パートナーアライアンス部の諸橋 (@moro) です。 突然ですが、わたしはいまクックパッドの「ユーザー基盤」を再構築しようとしています。 一口に「ユーザー基盤の再構築」といっても、そのゴールが何を指すかは(わたし自身にとってもまだ)漠然としており、固定されたゴールは見いだせていません。しかし後述するように、いくつかの問題は明確な形を取っています。言い換えると、それら明確な問題と向き合いながら『柔軟でいい感じのユーザー基盤を目指す』というのがこの再構築プロジェクトの目的です。 その第一歩目として、ユーザー登録部分を現状のクックパッド本体とは別の小さなRailsアプリケーションとして実装を進め、つい先日、一部の限定された利用者の方に向けて公開することができました。 今後も様子を見ながら公開範囲を拡大していく予定です。 再構築の背景 ではその「明確な問題」とはなんでしょうか。 最大
DHHはどのようにRailsのコントローラを書くのか | POSTD
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
似ているけどちょっと違うものたちをモデリングする技術 - hitode909
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016
例外設計における大罪 - 契約