タグ

設計に関するchostyのブックマーク (10)

  • 要件定義、基本設計、詳細設計の流れを総復習

    はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ?」 「基設計との違いって何だったっけ?」 「基設計と詳細設計の区別って?」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて1からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基を学びたい人 要件定義と基設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部(特に要件定義や基設計、詳細設計のサンプル)を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく

    要件定義、基本設計、詳細設計の流れを総復習
  • Twitterはタイムラインをどうやってキャッシュしているか - Qiita

    Twitterの内部構造を読解してみる 前口上 Twitterのようなマイクロブログサービスでは短時間で書き込みも多く、特にタイムライン周りは単にRDBのデータを出し入れるするだけではスケールしなくなります。 インターネット上に断片ながらTwitterの中の人がアーキテクチャについて解説した記事や動画がいくつか落ちていたので、Twitterがタイムラインをどうやってキャッシュしているかについてまとめてみたいと思います(推測を含みます)。 Twitterのテーブル構造 単純なTwitterのテーブル定義をRDBで定義すると以下のようになると思います。 tweets ツイート id user_id contents tweet_at followers フォロワー source_user_id destination_user_id users ユーザー id user_name timeli

    Twitterはタイムラインをどうやってキャッシュしているか - Qiita
  • DDDでの要件定義〜実装までの流れについて解説します

    記事では、ソフトウェア開発手法の一つであるDDD(domain-driven design)を使って要件定義〜実装を行う際のプロセスやポイントについてまとめていきます。 (書籍「ドメイン駆動設計モデリング/実装ガイド」の内容を大いに参考にさせていただいていますが、独自の内容・考察も記載しているつもりです。) DDD とは? DDD(domain-driven design)は日語に訳すとドメイン駆動設計で、ソフトウェア開発手法の一つです。 ドメイン駆動という言葉から、ドメインというものが重要そうだということは伝わってくると思いますが、そもそもドメインという言葉が抽象的でわかりにくいですよね。 ドメインは直訳すると「領域」ですが、DDD で指している「領域」とは「ソフトウェアで問題解決しようとする対象領域」です。 そして、① ドメインについての理解を深めてモデルを作成し(DDD では、後

    DDDでの要件定義〜実装までの流れについて解説します
  • ドメイン駆動設計の正体

    はじめに "ドメイン駆動設計は当たり前のことを言っているだけ" "ドメイン駆動設計はただのオブジェクト指向プログラミング" "ドメイン駆動設計はより良いアーキテクチャだ" "軽量DDDはアンチパターンだ" このようなドメイン駆動設計に関する言及を聞いたことがあるでしょうか? ドメイン駆動設計に言及する記事や書籍は多くありますが、それぞれ着目する側面が異なったり色々なコンテキストから言及されています。 おそらくそれが原因でドメイン駆動設計が何であるかをぼやけさせ、正体のわかりにくい概念になっているように思えます。 そこで今回は色々な観点から整理し、ドメイン駆動設計とは何であるのか、その正体を考えていきます。 ドメイン駆動設計の基的概念について ドメイン駆動設計はEric Evansが出版した「Domain-Driven Design」という書籍がルーツになっています。 ドメイン駆動設計を一

    ドメイン駆動設計の正体
  • Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える

    Java/Spring Boot/MyBatis/Thymeleafを使った、ドメイン駆動設計のサンプルコード。ビジネスルールに焦点を合わせ、計算モデルで複雑さを整理し、型指向のプログラミングで実装する、その具体例。

    Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
  • 10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由|ハイクラス転職・求人情報サイト AMBI(アンビ)

    10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由 10年以上運用されているサービスには、さまざまな技術的な負債が発生しています。今後の継続的な改善のため、いったん新規開発を止めて4年かけて全面的なリニューアルを実施した「はてなブックマーク」の開発者に、プロジェクトの課題や解決する手法などを聞きました。 改善1つに数カ月かかるなら全てを書き換えられないか 2000年代にトレンドだった開発手法の負債 過去の開発意図を探る考古学的手法 データセンター移行も見据えて刷新しよう ドメインモデル設計とScalaとマイクロサービス化 コアロジックにはScalaを採用 きちんとしたドメインモデルによる設計と実装を継続したい 段階的なリリースとデータの移行という2つの大きな課題 求められる機能に沿ったデータベーススキーマに再構築 新旧の2システムを維持しながら

    10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由|ハイクラス転職・求人情報サイト AMBI(アンビ)
  • 技術書典6で『Pragmatic Terraform on AWS』という本を出します #技術書典 - 憂鬱な世界にネコパンチ!

    タイトルどおり、TerraformAWSについて書いたを出す予定です。いま絶賛執筆中で、ちょこちょこ変わるかもしれませんが、だいたい構成が固まってきたので目次案を公開しておきます。 4/8追記 確定版の目次や無料サンプルを公開しているので、ぜひこちらもチェックしてください。 nekopunch.hatenablog.com nekopunch.hatenablog.com 概要 『Pragmatic Terraform on AWS』では、Terraformを使ってAWS上にシステムを構築するノウハウを、100以上のサンプルコードとともに紹介します。ECS Fargateなどのマネージドサービスを中心にアーキテクチャ設計を行い、Terraformで実装していきます。Terraformは入門的な内容からスタートし、コードの構造化やベストプラクティス、モジュール設計まで踏み込みます。 目次

    技術書典6で『Pragmatic Terraform on AWS』という本を出します #技術書典 - 憂鬱な世界にネコパンチ!
  • アーキ部:テーブル設計をやってみよう! - そこに仁義はあるのか(仮)

    毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) スピードラーニング的に@kawasimaさんのお話を聞く会ですが、今週はテーブル設計がテーマでした! この記事がすごく良かったので、触発されてブログ書く!!! developer.hatenastaff.com お題 ↓のお題が出て、テーブル設計を考えてみるはなし。 要求仕様は以下のとおり。 ・宿の部屋は、シングルやツインのような部屋タイプが設定できます。 ・宿側で宿泊プランを設定できます。宿泊プランは適用される日付が設定できます。 ・プランには複数の部屋タイプが含まれることがあります。 ・宿側でプラン・部屋タイプ・宿泊日ごとに宿泊費の設定ができます。 ・カスタマはプラン・部屋タイプ・宿泊日を指定して宿泊予約ができます。 ・予約は会員でも非会員でも可能です。 ・また、会員・非会員に関わらず、宿をお気に入りに登録でき

    アーキ部:テーブル設計をやってみよう! - そこに仁義はあるのか(仮)
  • ゲームエンジニアのためのデータベース設計

    DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。 This document discusses messaging queues and platforms. It begins with an introduction to messaging queues and their

    ゲームエンジニアのためのデータベース設計
  • 単一責任の原則(SRP) - Strategic Choice

    単一責任の原則(SRP:the Single Responsibility Principle) クラスを変更する理由は1つ以上存在してはならない。どういうこと?変更理由が2つあるということは、責任(役割)も2つあるということ。そんなジェネラリストなクラスを許さない、という原則。 ところで、「単一責任」って、クラスを作る上で一見当たり前に見える。責任(役割)をそのまま責任ではなく、変更理由としているところがポイント。 この見る角度を変えるところがこの原則の運用の大切な所。なんで?役割を複数もつクラスはもろいクラスだから。 複数の役割を担っているクラスがあって、それをある1つの理由で変更すると、関係のないその他の役割部分にまで影響を及ぼす事になり、その結果予想もしない形でクラスが壊れてしまう。 保守で違う人が修正したら簡単に壊れてしまう。 保守で変更していくと、実装的だけでなく、設計的にもよ

  • 1