設計タグ

累計

42
投稿
20
著者数
7909
総シェア数
1573
X
28
Facebook
4313
はてブ
1995
Pocket

直近1年

4
投稿
3
著者数

月別投稿数の推移

よく読まれている記事

AIネイティブ時代の設計書を考える

2026.06♡197

Webフロントエンド設計ガイドラインを公開しました

2025.09♡226

なぜアーキチームは設計や実装のパターンを絞りたいか？背景にある思考と技術選定のジレンマ

2025.11♡160

設計ドキュメント腐る問題、Git管理で運用してみた結果

2023.11♡666

署名付きURLを利用したファイルアップロードWeb API設計の勘所

2024.07♡361

I/F設計ガイドラインを公開しました

2025.08♡237

よく使われるカテゴリ

Programming 16本が所属
Frontend 6本が所属

新着記事

AIネイティブ時代の設計書を考える

Goならわかるシステムプログラミングなどのウェブ連載や書籍化でお世話になりまくりの鹿野さんのブログ記事が話題となっています。これを読んで、今までモヤモヤ思っていたことに光明が射してきたので、ちょっと実験してみました。

ラジカルAIプログラミング

本ドキュメントは、従来のプログラミング手法の限界を超えた、AI中心のプログラミング手法として、ラジカルAIプログラミングの概念を定義する。

なぜアーキチームは設計や実装のパターンを絞りたいか？背景にある思考と技術選定のジレンマ

アーキチーム（アーキテクト）やテックリードなどからの設計/開発のレビューで、こんな経験はありませんか？「その実装は、この機能ID BL310 の実装パターンでお願いします」

Webフロントエンド設計ガイドラインを公開しました

フューチャー社内の有志メンバーでWebフロントエンド設計ガイドラインを作成し公開しました！本ガイドラインではガイドライン策定の背景やガイドラインの特徴に加えて、内容の一部をピックアップしてご紹介します。

I/F設計ガイドラインを公開しました

フューチャー社内の有志メンバーでI/F設計ガイドラインを作成し、公開しました。本ガイドラインは、クラウドネイティブな環境におけるモダンなシステム間連携の設計指針を提供することを目指しています。

データフローダイアグラム本の献本をいただきました

データフローダイアグラムは1970年代に構造化分析の手法と一緒に考案された技法です。1990年代にはオブジェクト指向がさかんに取り上げられ、次世代のスタンダードとして喧伝されました。1997年代にはUMLが登場しました。

区分値設計再考

システムにおける「区分」とはカテゴライズ可能な値の集合体を表すものであり、「区分値」とはその集合に属する個々の識別子を指します。たとえば、あるアイテムの「ステータス」という区分には「下書き」「レビュー中」「承認済み」といった区分値が含まれます。

2025.03.21
設計データマネジメント区分値

署名付きURLを利用したファイルアップロードWeb API設計の勘所

現代のWebアプリケーションにおいて、ユーザが写真や動画などのファイルをアップロードする機能は、しばしば求められます。本記事では、ファイルアップロードを実現するための一手段として、「署名付きURL」を利用した方式を取り上げ、その設計について詳しく解説します。

OpenAPI Specification v3.0.3のコーディング規約を公開しました

フューチャーの有志メンバでOpenAPI Specification（OAS） v3.0.3に対応したコーディング規約を作成しました。

ぼくのかんがえたさいきょうのキャッシュ戦略

動作が遅いサービスはストレスがたまるので利用したくないですよね。例えばネットショッピングする際に商品ページの表示が遅かったり検索してもすぐに結果が表示されないとそのサービスを利用するのをやめてしまいたくなります。

設計ドキュメント腐る問題、Git管理で運用してみた結果

設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします

フューチャーのSwagger（OpenAPI 2.0）規約の紹介

フューチャーの有志メンバーでSwagger（OpenAPI Specification Version 2.0）のコーディング規約を作りました。

リアクティブプログラミングについて考える

前回のエントリーで、コンポーネント単位のステートをがちゃがちゃ更新していくという、オブジェクト指向型（オブジェクトの境界がコンポーネント）の考え方から、より小さな状態のインタラクションになっていくよ、という話を紹介しました。ビジネスロジックのアーキテクチャとしては、DDD本には以下の2つが書かれています。

ソフトウェア設計のトレードオフと誤りを出版しました

オライリージャパンから「ソフトウェア設計のトレードオフと誤り」の翻訳をフューチャーのメンバーと一緒に出版いたしました。好評なようで、発売一カ月ほどで増刷も決定いたしました。

データライフサイクルとトレードオフ

ソフトウェアの中身を大きく2つに分解すると、プログラムとデータに分かれます。データの表現にもいくつもの方針があって、それによるトレードオフがあるな、というのはもやもやと考えていたので、その考えをまとめて文章にしてみました

データベースと向き合う決意

「中間層を増やして柔軟性を高めるのがソフトウェアの歴史」これは大学時代に2つ上の先輩が言っていた言葉です。例えばマシン語を直接書くのではなく、アセンブラで書けば、変換（コンパイル）の手間はかかりますが、他のCPUへの移植はしやすくなります。

DynamoDB利用時の書き込みスキュー（Write Skew）の回避

一般的に複数のトランザクションが並行して同じオブジェクトに対してアクセスを行う場合には、トランザクションの分離レベル（SERIALIZABLE/REPEATABLE READ/READ COMMITTED/READ UNCOMMITTED）によって様々な問題が発生します。DynamoDBは2018年にトランザクションがサポートされましたが、本記事ではファントムリードによる書き込みスキューの問題とその対応について取り上げたいと思います。

ドメイン駆動設計の源流のPofEAAを読んでみる

最近、ドメイン駆動設計(以下DDD)とかそのあたりを読みこんでいる人から、DDD本の読み方を教えてもらいました。ここではDDD本はエリック・エヴァンスのドメイン駆動設計の方を参照しました。「DDDはパターンランゲージの形式を意識してるよ」ということでした。ただし、きちんとしたパターンランゲージの形式になっておらず、記述が著者のものになってるので、読者は注意して読む必要があるのかもとのことです

ソフトウェアのバージョンと開発スタイルの関係について

バージョンという言葉を身近に聞いたり、体感することは多いのではないでしょうか？ソフトウェア開発においてもバージョンは決して避けて通ることはできません。しかし、プログラムにバージョンをつける側に立ってみると、そもそもバージョンとは何なのでしょうか？ふわっと考え出すとわりときりがないと思います。

Class Widgets vs Functional Widgets

FlutterでWidgetを開発するとき、Stateless WidgetやStateful Widgetを継承したクラスを作成することが一般的だと思います。一方でクラスを定義せずとも、Widgetを返却するFunctionを定義することで同様のことが実現できるのでは？と考えたことはないでしょうか。

Project Haystackに関する備忘録

IoTに関するデータモデル標準化に用いられるProject Haystackについて調べる機会があり、日本語でまとめられている文献が少なくて理解するのに若干苦労したため、備忘録も兼ねて調査した内容を簡単にまとめておきます。Project Haystack は、ファシリティ・機器などの IoT に関するデータモデルを標準化する取り組みです。ビルシステムとそれに関連するデバイスのモデルを様々なツールで解釈できるようにするため...

A5:SQL Mk-2に回帰した話

みなさま、ER図を作成するとき、どんなツールを使っていますか？タイトル通りの出オチですが、数度の輪廻転生を経て私はA5:SQL Mk-2（以下A5M2）を使用しています。ツールをお勧めする記事は多数ありますが、意外と現場のリアルな事情を踏まえた投稿は見当たらなかったので、経験を踏まえてER図作成ツールの比較検討していきたいと思います。

PlantUMLのテーマ（思わぬ展開）

PlantUMLで使えるテーマについてのご紹介です。以前、チームで機能設計するためのPlantUML標準化の記事でも書かせていただきましたが、PlantUMLのデフォルトカラーって少しドライですよね。色の好みは人それぞれで、あれはあれでカッコよさはありますが、複雑な図は少しでも可愛く描きたい・楽しく見たいものです。

マルチクラウドを考えてみた

私は、企業へのクラウドのアーキテクチャ方針を考えたり、デザイン、構築などの仕事を主にしています。その際によくマルチクラウドの導入をしたい！という要望を最近受けることが多くなった気がします

Terraformerとしてコードを書いて思うこと

ここ最近はほぼ1からコード設計をして運用まで持っていくこともあり、「より腐りにくい、より息の長いコード」というものを考えるようになりました。Terraformだからこその「定期メンテを簡易にするためには」「より簡単に変更するためには」をひたすら突き詰めていった結果、アツい気持ちが生まれ、今回は筆を取っています。

12 次のページ