CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey
はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化
プラットフォームの上に劣化版のプラットフォームを作成してしまうアンチパターン「内部プラットフォーム効果」とはどういうものなのか
「ソフトウェア設計におけるアンチパターンの中に特にひどいにも関わらず文書化されていないものがある」として、ソフトウェア開発のためのハウツーガイドを提供するサイト「The Daily WTF」の設立者であるアレックス・パパディムーリスさんが「内部プラットフォーム効果(Inner-platform effect)」について投稿しています。 The Inner-Platform Effect - The Daily WTF https://thedailywtf.com/articles/The_Inner-Platform_Effect パパディムーリスさんは「システムをカスタマイズしすぎることで設計時に使用されたプラットフォームの粗悪なレプリカになってしまう」という現象を、「内部プラットフォーム効果」と命名しました。 内部プラットフォーム効果の代表的な例として、エンジニア以外でもデータベース
状態設計から「なんとなく」を無くそう
ウォンテッドリー株式会社の社内イベント "Tech Lunch" で話した発表です。 プログラムには大小さまざまな粒度の「状態」が存在します。 状態の設計を工夫することで、コーナーケースの発生を抑止し、ユーザー体験を最適化することができます。 本発表では、私が普段どのように「状態」について考えているか、言語や環境を問わずできるだけ普遍的に使える形での言語化を試みます。本発表を通じて、「状態」をなんとなくではなく合理的に設計するためのヒントを提供します。 GoogleスライドのURL: https://docs.google.com/presentation/d/1PNzz69UV05HlKPuWGlooemnPslLbLKsyLwl3R4U_XqE/edit
ミドルウェアとウェブフック
長くパッケージソフトウェアとしてのミドルウェアを開発してきて、ミドルウェアとウェブフックの組み合わせがとても良いと感じているので、雑にまとめていこうと思います。 まとめ ミドルウェアとウェブフックの組み合わせはお勧め。 戦略 ミドルウェアに永続化情報を持たせない ミドルウェアから直接データベースを引く仕組みを持たせない ミドルウェアにプラグインの仕組みを持たせない データベースを直接引く仕組みを持たせない 自分がミドルウェアを開発したときは、ミドルウェアがデータベースを引く仕組みを持っているというのが一般的でした。 ただこれ、どのデータベースに対応するのかという問題がでてきます。 PostgreSQL や MySQL や Oracle や SQL Server などなど、対応するデータベースが多いと、ミドルウェアの開発者は大変です。 RDB だけでなく LDAP や Redis といったデ
フロントエンドのディレクトリ構成を整理してコードの凝集度を高める
こんにちは、atama plus というスタートアップで web エンジニアをしている yubon です。 atama plus Advent Calendar 2023 の 7 日目になります。 本記事では、atama plus で実際に開発・運用している React プロジェクトにおいて、機能的な凝集度を高めるために行ったディレクトリ構成の再設計について紹介します。 フロントエンドのディレクトリ構成に関する考え方や設計思想は多くの記事で紹介されていますが、「業務で開発しているプロジェクトのコードで、ペインがある状態から再設計して実際に移行した」というケーススタディ的な記事は少なそうだったので、書き残しておこうと思います。
フロントエンドのディレクトリ設計思想
はじめに フロントエンドのディレクトリ構成、世の中に色んな「推し」が有って悩みますよね。 例えば、、、 さらに最近は、App Directoryの登場や、それに合わせたNext.js公式の「推し」構成がドキュメント化されたりと、さらに色々なパターンが出てきています。 本記事の趣旨 本記事では、具体的な構成そのものではなく、 様々ある構成を横串で見通して整理できる設計思想を紹介します。 新しい推し構成の紹介ではなく、構成を考えたり決めたりするときに役立つ抽象的・汎用的な指針を提供できればと考えています。 基本となる考え 分割の方向 一般的に、アーキテクチャにおける分割には2つの方向が有ります。 (出典も良書なのでリンクを貼っておきます： https://www.amazon.co.jp/dp/4873119820) これはディレクトリにおいても同じだと思っていて、筆者は分かりやすさのために
DIP(依存性逆転の原則)を守っていない話
一昨日くらいに 「DIP してもどうせ辛くなるよね」的なことを適当にツイートしたら引用 RT や RT 後言及やエアリプで言及された上に「こいつは設計を何も理解しとらん」みたいなことを言われた。「俺は本当に何も理解していないのか？」と不安になったので、自分の考えをちゃんと書いておこうと思った。先に自分の立場を言うと、なんたらアーキテクチャとか SOLID 原則は有用だし自分も使うが、それを厳守しようとは思っていないと言う立場だ。 DIP とはなんだったか DIP(依存性逆転の原則)は SOLID 原則の一つで、一言で言うと「抽象に依存させると依存関係が逆転する」といったものだ。何のことやらという風になるので例だけ挙げると、UserRepository と UserService があってこのように定義すると class UserRepository { get() { return dat
Guardian で巨大 Haskell レポジトリの依存関係を正気に保つ
TL;DR 巨大なモノレポはパッケージ間の依存関係に気を付けないと、変更が思わぬ所に波及して保守が大変だって？ DeepFlow 株式会社製ツール guardian を使って、Haskell モノレポのパッケージ間の依存関係が抽象化や意味論的な境界を侵犯していないかチェックしよう！ この度 OSS 化したので、巨大 Haskell モノレポの依存関係管理に困っている皆さんは是非試してみてください。 GitHub Action もあるよ。 はじめに - 巨大モノレポを保守する悲しみ 大量のパッケージから成るモノレポ[1]を管理するのが大変だというのは、あらゆる言語で共通の悩みであろうと思われる[2]。 こうしたモノレポというのは、「CIで全部ビルドできるようにしておく」というだけでは不十分で、ある箇所への変更が必要以上の部分のリビルドを惹き起こさないようにしないと、開発サイクルが全然回らずに
ラーメンの構造に学ぶ、コード設計 - そこに汎用性はあるんか （≠Rahmen編）
プログラムを使ってある仕様を実現するとき、多くの場合、そこに"唯一の答"はありません。 同じ仕様、機能を実現するコードにも多様性があります。 プログラミングにおいてしばしば問題になるのが、「その様々なコードのうち、どのコードを選んで実装するか？」ということです。 とりあえず機能が実現されるという点においてはどのコードを選んでも同じであっても、その後の保守性や拡張性などにおいて、自分がどんなコードを選んで書くか という事は重要です。 今の時点では正しく動作しているコードであっても、可読性や拡張性などの観点でクソコード、悪いコードなどと揶揄される場面がしばしば見受けられます。クソコードというのはかなり強い言葉で、あまり良い言葉だとは思わないですが、その言葉を発する人からすると、どうしてもそう言いたくなるような問題があるのでしょう。 ところで、同じ労力で悪いコードを避けて実装できるのであれば、そ
依存関係と階層構造の軛 - モナドとわたしとコモナド
21世紀現在のプログラミング言語において、モジュールという機能はほぼ必要不可欠である。ソースコードを分割し、明示的な依存関係を指定する仕組みであるモジュールは、以下のような様々な恩恵をもたらす。 インクリメンタルビルド: モジュールごとにコンパイル結果を保存し、変更されていない部分を再コンパイルするのを防ぐ。 内部の隠蔽: 実装の詳細を隠蔽し、モジュール外から触れないようにする。プログラムの見通しをよくしたり、不正な操作をする機会を減らす。 アーキテクチャの整理: モジュールは他のモジュールを参照できるが、原則として相互参照はしない。依存の向きを定めることで、適切な抽象化と、 それに基づいた実装の分離を促す。 さて、いくらモジュールが便利と言えど、数が増えすぎるとさすがに扱いにくい*1。そのため、ディレクトリの構造をモジュールの階層構造として運用する仕組みが備わっていることが多い。 コンパ
負債展 - ジンジャー研究室
技術的負債、色々あると思ったので並べてみた。 スピード重視負債「ビジネスが軌道に乗るまではスピード重視ね」 ビジネス要求の変化負債「頑張ってやってもらったけど、その機能もう要らないわ」 マーケティングの失敗負債「鳴り物入りでリリースしたのに誰も使ってくれない...」 要求分析失敗負債「この機能欲しいって言ってたよね...違うの...」 重要顧客負債「どうしても必要な機能だと言うので if 分岐で対応しますね...」 法改正負債「この実装だと今後はダメだって...」 上司の無理解負債「リファクタリングの時間が全然取れないんだけど...」 コーディング能力不足負債「なんで動いてるのか分からないけどヨシ...」 技術知識不足負債「そんな綺麗なやり方あったの知らなかった...」 怠惰負債「本当は共通化した方がいいけど、めんどくさいからやめた」 TODO 負債「// TODO: あとで時間がある時に
Managing State in Angular Applications
Victor Savkin is a co-founder of Nrwl. We help companies develop like Google since 2016. We provide consulting, engineering and tools. Managing state is a hard problem. We need to coordinate multiple backends, web workers, and UI components, all of which update the state concurrently. Patterns like Redux make some of this coordination explicit, but they don’t solve the problem completely. It is mu
クリーンアーキわからんかった人のためのクリーンじゃないけどクリーンみたいなオニオンに見せかけたSOLIDの話
依存関係逆転則含む諸原則に苦しめられた方々，いかがお過ごしでしょうか． 今回はアプリ設計の話です．と言っても，前回「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」というZenn記事を書いて，反響が大きかったのでリメイクしたいなという気持ちになり執筆することにしました． 前回同様，調べていく上で誤解していた部分や理解しにくかった部分を語った上で，オニオンアーキテクチャという，クリーンじゃないけどクリーンみたいな玉ねぎについて紹介するのですが，今回はわかりやすい図解であったり，実際にどのような実装をしていくべきなのかを話の話題として加えていければ良いかな？って思っています． これは前回の記事である「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」の記事の裏話的な話を一つさせてください． 今年の11月初め頃に，サポーターズという企業の学生が登壇できるLT会があり，私
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
逸脱事例を含めてすべてをレールに乗せる - fsubal
ライブラリやフレームワークの価値として、一定の制約を設けて典型事例をそのレールに乗せるというのがあると思う。それは書き方のルールであったり、あるいは受け取る値を型で制限することだったりする。 一方、現実のソフトウェアではたとえそういうフレームワークを使っていたとしても、時に逸脱する実装を取らなければいけないことがある。その時、フレームワークはその逸脱事例を 公式の方法として 書けるようにすべきかという問題が生じる。
Repositoryパターンのアンチパターン - Qiita
よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ
AmazonのAPI設計方針 (The Bezos Mandate) - Qiita
はじめに The Bezos Mandateという文書があります。日本語に訳すと「ベゾスのお達し」とか「ベゾスの勅令」でしょうか。 言わずと知れたAmazon.comのCEO、ジェフ・ベゾスが開発チームに通達した内容です。 これが（元Amazon.com従業員によって）公開されたのは2011年ですが、ベゾスがこのお達しを出したのは2002年前後です。17年経過した現在でも真理をついているどころかようやく時代がベゾスに追いついたかという感想です。 この記事ではThe Bezos Mandateの紹介と、僭越ながら補足説明も行います。 お達しの内容 原文は元Amazon.com従業員のGoogleエンジニア（公開当時）、Steve Yeggeによって公開されました。 Google+にStevey's Google Platforms Rantというタイトルで、Amazon.comと比べたGoo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Let’s Talk About State Management in Svelte