ソフトウェアの「詳細設計書」とはなんなのか - きしだのHatena
「設計書」というのは、作るものの構造を抽象的に表現したものと言うことができます。 ただ、ソフトウェアの抽象化の仕組みはプログラミングコード自体に備わっているので、ソフトウェア生成可能な抽象的表現というのはコード表現ができるはずですね。コードで表現しておくと、整合性のチェックとかも行いやすいです。 でも、コードではない「詳細設計書」というものが一部業界には必要とされているので、その「詳細設計書」というのは実際はなんなのか考えてみます。 ※ 最初はタイトルは「設計書」としてましたが、話を限定するため「詳細設計書」に変更しました。 追記：納品物に関する記述を追加しました。 表現を変えたコーディング ソフトウェア生成可能な抽象的表現というのはコード表現ができるわけですが、文字で表記する必要もなく、ダイアグラムで表現することもできますね。 代表的なのがER図やクラス図で、これは文字表現との相互変換が
テーブル・DB設計するときの極意 - Qiita
はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者（私）向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも？中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ！ ・テーブル・DB設計は「属性」と「関係」の２つだけ ・「属性」は必要なものを書くだけ ・「関係」は 1:1 / 1:N / N:N しかない（しかも、ほとんど 1:N） これが極意だ！！！ 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょう。 users / posts / comments / likes のテーブルが
新規作成画面をなくすと考慮事項が激減して嬉しい
例えば CMS の管理画面を考えます。 /posts に記事一覧画面、/posts/new に新規作成画面、 /posts/:postId に記事更新画面を置くような URL の設計はあるあるかと思います。 今回は /posts/new の画面はないほうが色々嬉しいと思った話をします。 新規作成画面があることで増える考慮事項 まず新規作成画面があると、どんな煩わしさがあるかを考えます。 下書き保存した時、どうする？ 新規作成画面で下書き保存をすると、内部的にはリソースの ID が採番されます。つまり下書き保存した段階で、それは記事更新画面になるはず。 その ID で URL を /posts/:postId に書き換えるかどうかを検討します。 筆者は React 一辺倒人間なので React 寄りの話にはなりますが、Next.js や React Router などでは /posts/ne
設計の考え方とやり方
#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計のためのモデリング
営業日などの規則性と例外を扱うための設計
解決したい問題 例として、飲食店の予約サービスを考える。 予約を受け付けるためには各店舗の営業スケジュールを管理しておいて、営業日の営業時間内のみ予約を受け付けるようにする必要がある。 たとえば、ある店舗は各曜日の営業時間について、以下のように定めているとする。 平日：11:30-22:00 土曜日：11:00-22:00 日曜日：11:00-21:00 定休日：木曜日 これを素朴に設計すると、たとえば以下のような「営業日については営業時間を保持し、定休日についてはレコードがない」というテーブルになるかもしれない。 店舗 曜日 開店時刻 閉店時刻
チームで高品質なコードを追求するための「設計標準」の育て方 / loglass coding standard
ログラスでは、チームとして高品質なコードを追求するために「設計標準」というものを定め、チームで育てています。 この資料ではそのような取り組みについてご紹介します。 株式会社ログラス会社紹介資料 https://speakerdeck.com/loglass2019/whats-loglass ウラ凸 - シリーズA 17億円調達のログラスのウラ側へ、カジュアル面談で突撃しよう https://meety.net/articles/t2--zrl4ohf4gx6 外部公開している設計標準の資料 https://little-hands.hatenablog.com/entry/2022/01/28/programming-principle https://little-hands.hatenablog.com/entry/2022/01/24/domain-object-design
ドメインロジックとSQL - Martin Fowler's Bliki (ja)
以下の文章は、Martin Fowler による Domain Logic and SQLの日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジック
3値論理
なぜ「= NULL」ではなく「IS NULL」と書かなくてはならないのか？ これは、気になっている人も多いはずです。まだ SQL に不慣れな頃、ある列が NULL である行を選択しようとして、 SELECT * FROM table_A WHERE col_1 = NULL; というクエリを書いてしまい、エラーになったり思い通りの結果が得られなかった、という経験は、ほぼ全ての人が持っているでしょう。ちょうど C言語や JAVA を習い始めのころに「if (a = 5)」と書いてしまう間違いとよく似ています。最初は、言語仕様の汚さにぶつぶつ文句をいいながらも、そのうち「IS NULL」という書き方に慣れてしまって、疑問を持たなくなります。 でもどう考えても奇妙な書き方ですよね。こんな素直でない書き方をしなくてはならないということには、やはりそれなりの理由があるのです。今からその理由を説明しま
データベース設計におけるNULL - kawasima
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
テーブル設計の考え方とやり方 [入門編]
「基本から学ぶテーブル設計 超入門！」 https://modeling-how-to-learn.connpass.com/event/242944/ の発表資料。 - ２つの設計スタイルの違いを理解する - 何を記録するか（資源・活動・当事者・規程） - どう記録するか（テーブルの役割…
![テーブル設計の考え方とやり方 [入門編]](https://cdn-ak-scissors.b.st-hatena.com/image/square/fff34d6fcb76b27f602c88a8a78045329642f395/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5416b70d025345fc95b30d1ec95701b6%2Fslide_0.jpg%3F20931325)
イミュータブルデータモデルの極意
6. Data / Inform / Information Inform: “to convey knowledge via facts (事実によって知識を伝える)” Data (Factの集合) Information 選択・加工して知識を取り出す Value of Values (Rich Hickey) 業務システム構築におけるデータモデリング (和田省二) 7. Dataを場合分けする Event (コト) Resource (モノ) 日時属性をもつ 日時属性をもたない 非対称性 対称性 ある一時点 ライフサイクルがある 一時点の事実の記録なので、属性は変わる ことはない。 ライフサイクルにともない属性が変化して いくこともある。 属性が変化しても同じモノであることを示 すためIdentityが必要。 データは大まかに2種類に分別できる。
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
プログラマの抱いている名前についての誤謬
パトリック・ミッケンジー（Patrick McKenzie）さんのブログ・エントリ、 “Falsehoods Programmers Believe About Names” の日本語訳です。翻訳の公開を快諾してくださったミッケンジーさんに感謝します。 公開: 2012-02-22 Posted on June 17, 2010 by Patrick きょう、ジョン・グレアム゠カミング（John Graham-Cumming）が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実
7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか？ もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす７つの設計原則 モジュール化 モジュール化の２つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事（ビジネスロジック）の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
設計の学び方：自分流のススメ
GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリです
Railsで考えるドメイン駆動設計のコアドメイン
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
