わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
Domain Modeling: What you need to know before coding
Starting to write code without proper planning is like trying to build IKEA furniture with a blindfold on. If against all odds, you somehow manage to assemble something resembling a dresser, there’s a good chance you’ve forgotten a crucial piece and you’ll be throwing the whole thing out in a week and heading to Pottery Barn (like you should have in the first place). [1] When getting to know a new
シンプルさの必要性 · eed3si9n
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 はいつもコミュニティーからかなり外れた人を選ぶらしく、今回は僕ということになりました。 僕の電話ボックスは外に駐車してあります。(会場、笑) だけど、今日は言語の壁を越える話題を持
後で楽できるTerraformの書き方（※ただし書くときは辛い） - SMARTCAMP Engineer Blog
はじめに ざっくりしたシステム構成の紹介 全体の構造 設計のポイント コーディング規約 上の階層を見に行かない 変数名は全体でユニークにする 変数のデフォルト値は設定しない main, outputs, variables 以外のファイルを原則置かない ポリシードキュメントはJSONファイルのまま管理する 変数で処理を変える仕組みを極力使わない 値のハードコードをためらわない コードが冗長であることをためらわない 残っている課題 AWSアカウント単位でしか用意しないものの扱い ECSのタスク定義の扱い 最後に はじめに はじめまして。スマートキャンプのおにまるです。 2022年10月に入社し、SRE兼インフラエンジニアとして働いています。 今回は、あるプロダクトの再スタートにあたって新しく作った、AWSのTerraformについてお話したいと思います。 再スタートにあたってアプリケーション
このユーザーはこの機能が使える、みたいなあれをどう実現するか
このユーザーはこの機能が使える、みたいなあれをどう実現するか 新しい記事公開しました！ 結論 DBで実現するかアプリケーション側でライブラリで実現する。casbinが強そうだぞ。 はじめに ユーザーテーブルにisAdminというカラムを使って、アドミンかそうでないかで、アクセスコントロールを分けていたが、サービスが大きくなり、もう少し細かくコントロールする必要になった。そこで、情報収集してえた見識をまとめておく。 アクセスコントロールという考え方を知る だれがこのファイルを操作できるのかみたいなやつ。おおきく4つのパターンがあるみたい。 DAC RBAC MAC ABAC DACとRBACとMAC この３つはまとめて図で理解したほうが覚えやすいと思う。 DAC(任意アクセス制御)はユーザー側が任意にこの機能を誰が使えるか設定する。例えばgoogleでファイル共有するときに誰までが閲覧可能か
業務システムにおけるロールベースアクセス制御 - Qiita
RBACの基礎 業務システムの権限制御の基本形はロールベースアクセスコントロール(RBAC)です。簡単化すると、以下のようなモデルです。 Subject(システムユーザ)は、複数のRole(ロール)を持っている。 Role(ロール)は、Permission(権限)のセットからなる。 Permission(権限)は、オペレーション(許可される操作)のセットからなる 具体的に、Redmineでの例をみてみましょう。 ユーザにはデフォルトで「管理者」「開発者」「報告者」のロールが割当可能である。 「報告者」ロールは、「Add Issues」の権限をもつ。 「Add Issues」の権限をもつユーザは、「Issueの新規作成」ができる。 このモデルをRedmineでは、以下のように表現しています。 Redmineは1人のユーザを、複数のプロジェクトに異なるロールでアサインすることができるので、上記
システムの権限管理を設計するときの考え方とは
システムの権限管理を設計することになったとき、どのようにすればいいか分からないかもしれません。この記事では、権限管理とは何か、その際に押さえておくべきRBACとABACについて、また権限管理を設計するときの考え方を解説しています。 私はエンジニアとして、主に立ち上げのフェーズでサービスを開発してきました。権限管理は、どのサービスにも必ず入ってくるプロセスでした。ここでの経験や、調べたことを元にこの記事を書いています。
マルチテナント SaaS を設計する際に参考になった資料 - Qiita
弊社 LIGHTz 初のアドベントカレンダー1発目でございます 弊社、絶賛 SaaS システムの開発中で、度々設計が議論になります。 そこで、備忘録も兼ねて参考になった資料を一言添えて挙げていきます。 ....... 一発目なのに備忘録の投稿をお許しください これから SaaS を作る皆様、↓もおすすめです。 リソースと分離編 マルチテナントSaaSのテナント分離をRow-Level Securityに移行した - Sansan Builders Blog 分離に関して各社の奮闘と生きた事例を見ることができます https://mitomasan.hatenablog.com/entry/2016/05/25/210151 あまり他の記事ではあまり言及されていない観点について述べられています url(ドメイン)設計 DBの接続先の切り替えはユーザーのリクエストを処理する最初の段階でフレーム
Markdownでシーケンス図とかが書けるMermaid記法で業務フローを書いたら意外とイケたので自分なりのコツを紹介してみる | DevelopersIO
こんにちは、臼田です。 みなさん、業務設計してますか？(挨拶 今回はMarkdownでシーケンス図やフローチャートなどの図を記述できるMermaidを使って業務フローを書いてみたら、意外と書けたので自分なりのTipsを紹介したいと思います。 その前に 注意点として、まだMermaidを使い始めたばかりなので、「もっとこうしたらいいぞ」とか「こっちのほうがいいぞ」とかあれば建設的なフィードバックとしてSNSとかでいただけるとありがたいです。 あと業務フローって表現しましたが、人によって思い描く業務フローが違うと思うので、業務フローの定義に関するツッコミはご容赦ください。私が今回Mermaidで書いたのは以下の図です。(内容はブログ用に簡素化しました) この図のコードは以下のとおりです。(後ほど解説します) sequenceDiagram autonumber actor お客様 partic
PHPerKaigi 2022: 予防に勝る防御なし - 堅牢なコードを導く様々… / 和田卓人
PHPerKaigi 2022 のセッション動画です。 2022/04/10(40分) スピーカー: 和田卓人 ( @t_wada ) タイトル: 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。 https://fortee.jp/phperkaigi-2022/proposal/ef8cf4ed-63fe-42f8-8145-b3e70054458b
DataflowとBigQueryで始める大規模データ分析基盤実装入門 - TECH PLAY Magazine
大量に蓄積されたデータを活用するためには、データ分析基盤の構築が必要になる。だが、専門知識を持つ人材やデータ分析にかける予算確保は容易くはない。そこで、電通国際情報サービス(ISID)の全社横断的な研究開発部門である、X（クロス）イノベーション本部ソフトウェアデザインセンターの佐藤太一氏が、自らの経験をもとにDataflowとBigQueryで大規模データ分析基盤を実装する方法を紹介。その際に重要となるコスト観も合わせて解説した。 データ分析基盤構築における考え方とシステムアーキテクチャ 佐藤 太一氏 株式会社電通国際情報サービス(ISID) Xイノベーション本部 ソフトウェアデザインセンター 今回登壇した佐藤太一氏が所属する電通国際情報サービス（以下、ISID）のXイノベーション本部は、全社横断的な研究開発部門。佐藤氏はGitHubやJIRAなどの現代的な構成管理ツールの利用促進や部門横
1000万ユーザに耐えるサーバを作ってみた
概要 スケーラビリティが高く1000万ユーザに耐えるAPIサーバを作成しました。TwitterのようなSNSです。実装はGitHubで公開しています。 開発環境は次の通りです。 Node 16.14 Express 4.17.3 DynamoDB 2012-08-10 機能要件は次の通りです。 ツイート機能 ツイートに対してコメント機能 フォロー機能 タイムライン機能 導入 Facebook、Amazon、Youtubeのような数億人のユーザを抱えるサービスでは大量のトラフィックを捌く必要があります。大量のトラフィックを捌くためのアプローチとして一般的に使われるのはスケールアップではなくスケールアウトです。スケールアップは性能の高い機器を使うためにコストが高いです。また、1つのサーバで運用するためにパフォーマンスの限界が存在します。 スケールアウトについて考えます。アプリケーションは大きく
なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
CyberZ が Amazon DynamoDB を使用してフォロータイムラインの表示に必要な Read-Light 方式を実現した方法 | Amazon Web Services
Amazon Web Services ブログ CyberZ が Amazon DynamoDB を使用してフォロータイムラインの表示に必要な Read-Light 方式を実現した方法 CyberZ について CyberZ はスマートフォンに特化した広告マーケティング会社として 2009 年に設立しました。スマートフォン広告における運用・効果検証、交通広告やウェブ CM の制作など、幅広いマーケティング事業を展開しています。日本に加えて、サンフランシスコ、韓国、台湾にも支社を構え、国内広告主の海外進出および海外広告主の日本展開支援も行っています。また、メディア事業として動画配信プラットフォーム「 OPENREC.tv 」、 e スポーツ事業として、国内最大級のeスポーツイベント「 RAGE 」を運営しています。 CyberZ 100 % 子会社としては、オンラインエンタテインメント事業、プ
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方
この本の概要 「ITエンジニア本大賞2023」技術書部門で大賞受賞！ 本書は，より成長させやすいコードの書き方と設計を学ぶ入門書です。 システム開発では，ソフトウェアの変更が難しくなる事態が頻発します。コードの可読性が低く調査に時間がかかる，コードの影響範囲が不明で変更すると動かなくなる，新機能を追加したいがどこに実装すればいいかわからない……。 変更しづらいコードは，成長できないコードです。ビジネスの進化への追随や，機能の改善が難しくなります。 成長できないコードの問題を，設計で解決します。 こんな方におすすめ コードの設計スキルに興味がある人 日々，悪いコードと向き合っていて改善したい人 より良いコードを書きたい人 1 悪しき構造の弊害を知覚する 1.1 意味不明な命名 1.2 理解を困難にする条件分岐のネスト 1.3 さまざまな悪魔を招きやすいデータクラス 1.4 悪魔退治の基本 2
Repositoryパターンのアンチパターン - Qiita
よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ
急成長するLINE配信対象ユーザー数にGCPアーキテクチャの改善で立ち向かった話 - ZOZO TECH BLOG
はじめに こんにちは、EC基盤本部・MA部・MA基盤チームでマーケティングオートメーションのシステムを開発している長澤（@snagasawa_）です。この記事では、社内で運用しているLINEメッセージ配信基盤の課題を、アーキテクチャ改善によって解決した話をご紹介します。 当時、LINEメッセージ配信基盤では、配信処理を担っていたApp Engineで2つの課題を抱えていました。「メモリ不足による配信処理の中断」と「リクエストタイムアウト後の意図しない処理の継続」です。一時はスケールアップによるメモリ増強を検討しましたが、後者の課題を解決できないためアーキテクチャの変更に着手しました。 結果として、App Engineが担っていた処理をBigQuery・Cloud Storage・Dataflow Batch Jobに置き換えることにより、この2つの課題を解決しました。加えて、配信対象ユーザ
JIS X 20246:2021 ソフトウェア及びシステム技術―ソフトウェア及びシステム開発における作業生産物のレビューのプロセス
JIS X 20246:2021 ソフトウェア及びシステム技術―ソフトウェア及びシステム開発における作業生産物のレビューのプロセス | ページ 4 14 X 20246 : 2021 (ISO/IEC 20246 : 2017) 附属書A (規定) レビューの文書化 A.1 概要 この附属書では,要検討事項ログ,インシデント報告書及びレビュー報告書に含めなければならない情 報について規定する。しかし,具体的な記録のためにここで提供する命名体系を利用することは必須では なく,他の用語を使用してもよい。実際には,これらは単一の文書として発行する必要はなく,電子形式 で利用可能としても,別々の文書に分割しても,又は他の文書と組み合わせてもよい。 非形式的レビューが行われる場合,この附属書に定義した形式的な文書化は必要ない。 表A.1は,レビューの文書化に対する要求事項を,各文書に固有の情報ごとに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CtoCフリマアプリの作り方 〜6ヶ月間のPayPayフリマ開発を支えた設計〜 / YJTC19 in Shibuya A-6 #yjtc | ドクセル