About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)

はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか

プロダクト開発における ソフトウェアサプライチェーンセキュリティ: 実践的フレームワークとその活用 / Software Supply Chain Security in Product Development: Practical Framework and their applications

2023年4月11日に開催されたクラスメソッド株式会社のイベント、DevelopersIO DayOne で発表したスライドです。 「モノリスかマイクロサービスか、その選択に迷っている人へ届けたい話」をマイクロサービス導入ステップやチーム作りの観点から解説しました。

やれやれ、私事で色々あって、あっという間に3週間経ちました。 最近SOLID原則とかいろいろと本を読んでいます。以下の内容は主にこちらの本からの抜粋と感想となります。 実体験でもありますが、これらのフィロソフィーレベルの話を軽視、疎かにする人も周りに割といます。結局的にチーム全体にマイナスになってしまうケースもしばしば。やはり常に念頭に置いておかないとですね！ 一般論的に「良いコード」とは まず一般的にいわば「良いコード」にはどういう特徴があるかについての内容です。本には第３章辺りの内容となります。 契約式設計(Design by Contract) システムを設計する際に、数多くのモジュールがそれぞれの役割を担当していて、同時に互いに協同作業しています。協同作業する時に他のクラスからメソッドを実行、いわばAPIを使う時に、クライエント側（実行側）とサーバー側（API提供側）がインプット、

リーダブルコード的な本が新たに登場っす！ (しかもKotlinなの) 読書記録と感想です。著者の石川宗寿さんはLINEでご活躍中のシニアエンジニア。元は2019年に公開されたプレゼンテーション「Code Readability」を元に書籍化されたとのことで、モダンな大規模開発やコードレビューやリファクタリングで得られた現場の経験を通して、可読性の高いコードを大テーマに知見が詰まった一冊となっています。 リーダブルコード的な本が新たに登場っす！ (しかもKotlinなの) 第1章　可読性の高いコードを書くために 第2章　命名 第3章　コメント 第4章　状態 第5章　関数 第6章　依存関係 第7章　コードレビュー まとめ：Kotlinを題材にした2020年代のモダンなコード指南の書 おまけ リンクと関連書籍 読みやすいコードのガイドライン -持続可能なソフトウェア開発のために 作者:石川 宗寿

はじめに アーキテクチャ・デザイン全般 ソフトウェアアーキテクチャの基礎 Clean Architecture　達人に学ぶソフトウェアの構造と設計 Design It! ソフトウェアシステムアーキテクチャ構築の原理 データ指向アプリケーションデザイン マイクロサービス マイクロサービスアーキテクチャ マイクロサービスパターン 実践的システムデザインのためのコード解説 ソフトウェアアーキテクチャ・ハードパーツ ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本 現場で役立つシステム設計の原則 要件定義 はじめよう！プロセス設計 ～要件定義のその前に はじめよう！ 要件定義 ～ビギナーからベテランまで はじめよう！システム設計 ～要件定義のその後に Web, Web API Webを支える技術 プロになるためのWeb技術

【オブジェクト指向】全23種類のGoFデザインパターンに関する説明と参考書籍 by nao · 公開済み 2021年1月7日 · 更新済み 2021年5月15日 Gang Of Fourデザインパターンを学ぶメリット Gang of Fourのデザインパターンとは、「よく見かける機能要件（解決したい問題）」と「各機能要件に対応する設計方針」を23種類に整理したものです。例えば、「単一リソースにアクセスする場合はSingletonデザインパターンが良い」というように、機能要件に適した設計（デザインパターン）を提案しています。 デザインパターンの初出は1995年であり、その有用性がある程度理解されてきたので、オブジェクト指向による設計での基礎知識となりつつあります。デザインパターンが最善の設計方法ではない事もありますが、それを理由にデザインパターンを学習しないのは早計です。 個人的には、デザイ

この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA（ラドラ）とは？ 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD

概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて