GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.
Architecture styles define how different components of an application programming interface (API) interact with one another. As a result, they ensure efficiency, reliability, and ease of integration with other systems by providing a standard approach to designing and building APIs. Here are the most used styles: SOAP: Mature, comprehensive, XML-based Best for enterprise applications RESTful: Popul
〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録 - スタディサプリ Product Team Blog
こんにちは。スタディサプリのWeb開発をやっている@highwideです。 今日は、自分の所属する"コーチングチーム"(個別指導コースや合格特訓コースの機能開発を行っています)が、最近のプロジェクトで利用した「アーキテクチャ・デシジョン・レコード」、通称「ADR」について紹介したいと思います。 アーキテクチャ・デシジョン・レコード(ADR)とは 「ADR」「アーキテクチャ・デシジョン・レコード」という概念を知ったのは、社内で行っていた「Design It! プログラマーのためのアーキテクティング入門」(以後「Design It!」)の読書会でのことでした。 www.oreilly.co.jp 最初にそのキーワードが登場する「11.2.3 必要なときだけ形式的な記述に投資する」では、「"膨大な量のドキュメントになる傾向"がある形式的なドキュメンテーション」に対比して、以下のように紹介されます
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
コナーセンス(翻訳)
コナーセンスとは コナーセンスはソフトウェアの品質メトリクスであり、結合度の分類方法です このサイトではさまざまな種類のコナーセンスをコードの改善に役立つ実例付きで紹介しています。 変更の可能性 あらゆるコードに変更の可能性があります。現実世界が変化するのに合わせて、私たちのコードも必ず変更されます。コナーセンスは、長期的な観点から柔軟性のあるコードを書くにはどうすればよいかについて洞察を提供してくれます。コードベースの柔軟性を維持することは開発速度を長期的に維持するために不可欠です。 柔軟なメトリクス コナーセンスはメトリクスであり、他のメトリクスと同様に不完全な測定値です。しかし、コナーセンスはより包括的なアプローチを取っています。コードベースのコナーセンスは以下の３つの独立した軸で判断する必要があります。 強度。コナーセンスが強いと発見が難しい、またはリファクタリングが難しくなります
Connascence：コードの結合度を測るもうひとつの指標 - snoozer05's blog
構造は、凝集度が高く、結合度が低い場合に安定する - Larry Constantine 私たちプログラマーは、その仕事において、できる限り良いコードを書きたいと考えます。しかし、「良いコードとは何か」という問いに対して答えるのは、そう簡単ではありません。「良さ」を測るには、「何に対して」という軸が必要であり、その軸は一つではなく、さらには、コードを書いている状況に応じて、大事にすべき軸が変わるということも往々にしてあるからです。そうしたとき、私たちは何らかの尺度でもってコードを測って、そのときのコンテキストにおいて良い落とし所を定めます。 そのようなときに、コードの品質を測る軸としては、有名なものには「凝集性（Cohesion）」と「結合度（Coupling）」があります。ここでは、そのうちの「結合度」を測る指標の一つとして「コナーセンス（Connascence）」を紹介します。 コード
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク（40分） PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。 Agenda - 型宣言 - 列挙型 - ドメインモデリング - 不変性と等価性 - 完全性 - レイヤーと責務
これだけは押さえよう！住所フォームの作り方 - ケンオールブログ
まとめ 住所フォームの作り方 住所フォームを作るときには以下の4つを押さえましょう。 オートコンプリート機能に最適化する 郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する モバイルUX優先なら郵便番号が入力されたら即座に補完。精度優先なら郵便番号補完ボタンを設置 住所フィールドは「都道府県」「市区町村」「町名以下」の3フィールドが基本。「建物」フィールドはオプション 本文 地域SNSのユーザー登録、ECサイトの配送先入力、資料請求、自治体サイトでの電子申請など、ウェブサービスを活用する上で住所入力は欠かすことができません。 住所入力をシンプルかつ正確に行えるような入力インタフェース（住所フォーム）は、離脱率を減らし、コンバージョン率を向上させる上で重要です。 郵便番号を入力すると対応する住所を自動入力する機能（郵便番号による住所補完）は、住所フォームの改善方法として最も効
【初心者向け】「AWS 設計のベストプラクティスで最低限知っておくべき 10 のこと」を受講しました。 | DevelopersIO
どうもさいちゃんです。 AWSには利用者が仮想環境を構築していくのに役立つベストプラクティスと呼ばれるものがあります。 これからAWSでガンガン仮想環境を構築していくにあたって設計のベストプラクティスを復習してみようということで、今回はAWS公式から出ている「AWS 設計のベストプラクティスで最低限知っておくべき 10(+1) のこと」という動画を視聴したのでご紹介をしていきます。 登録さえすれば、無料で動画の視聴と資料のダウンロードができます。 こちらから受講が可能です。 はじめに このセッションはAWSにおける設計おベストプラクティスの理解を深める目的で、 クラウド導入を検討している方 オンプレミスからクラウドへの移行を検討している方 クラウドを使い始めたがベストプラクティスを適用できているか悩んでいる方 向けに細かくわかりやすくベストプラクティスについてを説明しているものになります。
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
WEBフロントエンドにおけるソフトウェア設計の考察 / Consideration of software design in WEB front end
概要 ・現代Webフロントエンドにおける難しさは何によってもたらされるのか ・Webフロントエンドと「ドメイン」の関係について ・Webフロントエンドを「設計」することについて ・Webフロントエンドにおけるアーキテクチャ考察 参考資料（スライドにも記載） ・エリック・エヴァンスのドメイン駆動設計 ・Eric Evans（著）今関 剛（監訳）和智 右桂、牧野祐子（訳） ・Clean Architecture 達人に学ぶソフトウェアの構造と設計 ・Robert C. Martin（著）角 征典、高木 正弘（訳） ・未来を作った人々 - ゼロックス・パロアルト研究所とコンピュータエイジの黎明 ・Michael Hiltzik（著）エ・ビスコム・テック・ラボ（監訳）鴨沢眞夫（訳） ・オブジェクト指向のハードコア ・https://www.zerobase.jp/salon/2019/05/25/
システム開発にUMLを適用するためのFAQ
※本稿は、著者達が1年前に執筆したCQ出版社刊 『Design Wave Magazine 2004 December』 [9] の記事を参考に Web へ公開したものです。 目次 UMLはオブジェクト指向なしで使えるのでしょうか？ UMLには図がたくさんあるが、全部使う必要はあるの？ いつ、どの図を使うべき？ 忙しくてモデルを書いている時間はない。ほんとうにモデルを書く必要があるの？ オブジェクト指向は、私の担当している組み込み製品にとってはオーバースペックなのではないかと思うのですが？ タスク、割り込み等、組み込みシステム特有の概念をUMLで表現できるのか？ 今からUMLを始めるのだが、UML 2.0を学ぶべき？ 製品知識は分かっているのに、分析する意味はあるの？ 機能が多すぎてユースケースが爆発してしまいます。ユースケースの管理しやすい方法を教えてください。 「問題領域の概念を抽出す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリケーション設計の第一歩は
ディレクトリの整理から / Encraft 1
GitHub - smithy-lang/smithy: Smithy is a protocol-agnostic interface definition language and set of tools for generating clients, servers, and documentation for any programming language.
system-design-primer/README-ja.md at master · donnemartin/system-design-primer
抽象化って何？ (What is abstraction?)
実践ADR - kawasima
GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリです
GitHub - globtec/phpadr: A PHP based command-line interface tool for working with Architecture Decision Records (ADR)
技術選定の審美眼 / Understanding the Spiral of Technologies
アーキテクチャ決定のお供にLightweight architecture decision records
