はてなブックマーク

ユーザなどのリソースエンティティのパージするわけではないデータ削除(a.k.a. 論理削除)をどう設計するか、は単純でありながら、イミュータブルデータモデルの基本形を学ぶ良い題材なので、順を追って説明する。 リソースの検討 まずユーザがアクティブなユーザと削除されたユーザで扱いが異なるかどうかを考える。この段階で物理設計としてどうするかを考えると検討ポイントが十分考慮されないことにつながるので注意しよう 。(イミュータブルデータモデル#5e3a5f1da8e5b200009c0499) 扱いが異ならない場合を考えてみよう。 code: (mermaid) classDiagram direction LR class ユーザ { <<Resource>> ユーザID : SERIAL PK 名前 : VARCHAR メールアドレス : VARCHAR ユーザ区分 : ENUMアクティブ/削

ドメインモデリングにおいて、エンティティ間の関連(リレーションシップ)をどのように表現するかは、システムの保守性や拡張性に大きく影響する重要な設計判断となる。 なぜ関連のモデリングが重要か 関連の設計が不適切だと、以下のような問題が発生する: 不変条件の検証が困難になり、データ整合性が保てない パフォーマンスの問題(N+1問題、過剰なメモリ使用) ドメインロジックの複雑化と保守性の低下 集約境界の破壊によるトランザクション管理の困難 データベースレベルでは、多対多の関連は交差テーブルを用いて表現されるが、ドメインモデルではより多様な表現方法が存在する。それぞれの設計選択は、パフォーマンス、メモリ使用量、コードの複雑性、ドメインロジックの表現力などに異なる影響を与える。 スキーマの例 まず、典型的な多対多リレーションのデータベーススキーマを見てみよう: code:sql -- 学生 CREA

JJUG CCC 2025 Spring で話したものです。 昨今の生成AIによって、偶有的な難しさは激減した。し、これからも減り続けることだろう。 だが、本質的な難しさ(複雑さ)が変わるわけではない。 「本質的な複雑さ」とは何か? 本質的な複雑さにはどうアプローチすれば良い? 本質的な複雑さはどう設計しても変わらない。 すなわち本質的複雑さは保存法則がある。 だが、本質的複雑さはその度合いに応じてComplexとComplicatedの複雑さがある。Complexな状態では、本質的複雑さがどれだけ含まれているかが把握できないことがある。動かしてみないと分からない、動かしてみても分からないことも... したがって、データモデリングを通じて「時間と労力さえかければ理解可能」な状態にしておくことが重要。 Complicatedな状態に持っていくために、イミュータブルデータモデルでモデリングすると良

2025年4月24日に開催した #アーキ部 『丁度ええ! ロギング』の内容を編集したものです。 ロギングにまつわる問題の構造 ロギングにまつわる現場でよく見られる問題には以下のようなものがあります。 ロギングガイドラインを定義して、開発者に周知し実装してもらったが、実際運用してみると、役に立たないログが多すぎる。 担当者が異なると、ログ出力する粒度が微妙に異なり、解析に時間がかかる。 ログの形式や内容が統一されておらず、分析ツールでの活用が難しい。 ロギングベストプラクティスは探すといくつか見つかります。 https://www.dataset.com/blog/the-10-commandments-of-logging/ https://betterstack.com/community/guides/logging/logging-best-practices/ https://new

バリデーション解体新書 2025年4月8日に開催した #アーキ部 『バリデーション解体新書』の内容を編集したものです。 バリデーションとは何か? 広義には、 何らかの処理を実施するにあたって、入力データが想定する条件を満たすかを検証する行為 と言える。 この定義で、アプリケーションのどこでバリデーションをしているのかを考えると、以下のように各層にそれが見られる。 このように実装される場所が散らばるので、「バリデーション」や「入力チェック」を分類して開発ガイドラインを作ることが多い。 例えば、大規模Java開発向けのTERASOLUNA開発ガイドラインを見てみると、 ユーザーが入力した値が不正かどうかを検証することは必須である。 入力値の検証は大きく分けて、 1. 長さや形式など、文脈によらず入力値だけを見て、それが妥当かどうかを判定できる検証 2. システムの状態によって入力値が妥当かどうか

飛べない鳥問題がオブジェクト指向設計における継承の誤った例として度々挙げられる。 https://qr.ae/pYOBqZ ハトやカラスは鳥であり、鳥は空を飛ぶのでfly()という振る舞いを持つ。 code:mmd classDiagram class 鳥 { fly() } class ハト { fly() } class カラス { fly() } 鳥 <|-- ハト 鳥 <|-- カラス ところが、新たにペンギンを加えようとした時に問題が起こる。ペンギンは明らかに鳥であるにもかかわらず飛べない。これは、どう対処したら良いか? code:mmd classDiagram class 鳥 { fly() } class ハト { fly() } class カラス { fly() } class ペンギン { fly() //飛べない!! } 鳥 <|-- ハト 鳥 <|-- カラス 鳥

このSpring Bootを使ったクリーンアーキテクチャの例は、データの詰め替え過剰にみえる。 https://www.baeldung.com/spring-boot-clean-architecture これだけのモデルと詰め替えが必要なのだろうか? 『Get Your Hands Dirty on Clean Architecture 』にこのマッピング戦略(詰め替え戦略)が書かれている No Mapping (レイヤ間でモデルを共有し、詰め替えをしない) 2-way Mapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しは上位レイヤが詰め替えの責務を負う) Full Mapping (各レイヤで独自のモデルを持ち、レイヤを跨ぐ呼び出しには専用のモデルを使う) またこの戦略のどれを選ぶかの基準は『Balancing Coupling in Software Design

2024年7月13日の大吉祥寺.pmで発表した「古典ドメインモデル(パターン)の解脱」のスライドログです。 この2冊で書かれているドメインモデルパターンを「古典」の対象にします。 ドメインモデルパターンは「複雑さに対処するため」と述べています。が、古典では次の2点が課題となっていると考えます。 これら2点について個別に見ていきます。 まずドメインモデルパターンから。 Patterns of Enterprise Application Architecture(以降PofEAA)ではこのように定義されています。 PofEAAのドメインロジックの章で使われている「収益認識」の例を取り上げます。 ContractやProduct, RecognitionStrategyなどといったクラスが作られて、これらのインタラクションでビジネスロジックが実現されると説明されています。 では、これらのドメイ

固定長メッセージのような以下なる変更も、破壊的変更となってしまう場合の対策としてこの手段が一応理に叶うことがある。

#アーキテクチャ大全 設計のポイント 付与率の計算 顧客ランク (ロイヤルティ) 還元率アップキャンペーン 期間限定 店舗限定 ポイント付与のタイミング 即時 後日 キャンセル可能なアクションを伴うポイント付与は、キャンセルできなくなるタイミングまで実際の付与を遅らせる。 ただし、付与予定としてユーザに見せるケースがある。 ユーザがキャンセルした場合は、付与予定を取り消す。 有効期限 固定(dポイント型) 使うたびに延びる(ヨドバシ型) 期間限定ポイント キャンペーンとして有効期限の短いポイントを対象ユーザに一斉に付与する。 ↑の有効期限が使うたびに延びるタイプでも、期間限定ポイントは固定の有効期限を持つ。 参考資料 https://it-koala.com/point_system-814#i-4 https://engineering.reiwatravel.co.jp/blog/ne

1はこれが出来る場合と出来ない場合がある。上記例のように割り算の場合、どんな数字をデフォルト値にしようとしても不適切なので、この対策は取れない。(従業員とボランティアの2つのクラスがあって、給与支払額を算出する、という計算においてはボランティアは0円を返す、みたいな手段は取れる)

ソフトウェア開発におけるContinuous 〇〇を収集する。総じて作業負荷、心的負担が大きくなるバッチ処理的に溜めて一度にやっていたプロセスを、日々のライフサイクルの中に組み込むことが目的である。 Continuous Integration すべての開発者の作業コピーを定期的に共有されたメインラインにマージする。 Wikipedia eXtreme Programmingでの説明 Martin Fowlerによる解説 Continuous Delivery 継続的デリバリーとは、新機能、設定変更、バグ修正、実験など、あらゆる種類の変更を、安全かつ迅速に、持続可能な方法で本番環境に導入し、ユーザーの手に届けることができるようにしておく。 Wikipedia Martin Fowlerによる解説 Continuous Deployment ソフトウェアを頻繁に、自動的にデプロイメントする。

統計情報が取得できておらず、SQL実行時間が長くなったりデータベースのリソースを喰ってしまったりする。

日本語だとどちらも「複雑」を意味するが、英語だと「Complex」と「Complicated」の2つの単語が該当する。 両者は明確な違いが無いともされるが、使い分けられるケースもある。Complicatedの方が頑張れば解消可能とされ、「複雑」じゃなく「込み入った」という訳語があてられることもある

NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。

マーチン・ファウラー命名のドメインモデル貧血症は、ドメイン層っぽいデータをもつクラスを作りながらも、フィールドのGetter/Setterだけをつものを指す。そうしちゃうとドメインオブジェクトに業務知識が実装されず、それを使う側に任されることになる。

会員のドメインモデルを考える。属性としてemailAddressを持っていて、これは通知メールを送るのに使われる。

コンテンツサイトの「記事」を、あらかじめ掲載開始予定日を設定しておき、その日がきたら記事が公開される、また掲載終了予定日を設定しておいて、その日がきたら記事が非公開になる、というモデルを考える。

Domain Modeling Made Functionalで紹介されているドメインのドキュメンテーションを元にミニ言語を定義する。 データの定義 dataキーワードの後に、データを表す名前と、「=」を挟んでそれを構成する要素で表現する。 ANDで繋いだ構成要素は、いずれもそれらがパーツとして必要とされることを示す。すなわち、以下のような表記では、 code:注文 data 注文 = 注文番号 AND 住所 注文が注文番号と住所からなることを示す。 ORで繋いだ構成要素は、どれか1つが選択されることを示す。すなわち以下のような表記では、 code:注文 data 連絡手段 = Eメールアドレス OR 電話番号 連絡手段がEメールアドレスまたは電話番号からなることを示す。 構成要素の末尾に「?」を付ける場合 code: 顧客 data 顧客 = 氏名 AND Eメールアドレス? 構成要素が

ドメインモデルには、完全性と純粋性、そしてアプリケーション性能の3つ全てを同時に満足させることは難しい場合があるという話。

JavaScript syntax defines several native data types that are not included in the JSON standard: Map, Set, Date, Error, Regular Expression, Function, Promise, and undefined.

このツールは、全体的な傾向を把握するためのもので、意図的に不正確な指標になっている。そのため個人の仕事のパフォーマンスを評価するために使ってはいけない。

#アーキテクチャ大全 ここでは画像やPDFなどの文書ファイルをアップロードし、別のWebページで画像を表示するのに使ったり、別のユーザにアップロードした文書ファイルを見せたりダウンロードさせたりする用途を考える。 ExcelやCSVなどのデータをシステムに取り込むためのアップロードに関しては、別途記す。(至高のファイルアップロード みたいなやつ) 設計のポイント アップロードさせるファイルの種類 ファイルアップロードダイアログで拡張子制限できる。 バリデーションとしては、Mime-typeだけでなく、ファイルに含まれるマジックナンバーをチェックしておくとだいぶ安心感がでる(もちろん完全ではないので、ウイルスチェックも併用すること)。 https://medium.com/the-everyday-developer/detect-file-mime-type-using-magic-num

Eberhard Wolffさんのこのプレゼンの要約です https://www.youtube.com/watch?v=B3O-qYM-Kkw 共通のデータモデル 共通のデータモデルを通信に使う 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、す

型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。

論理的なLayerは、コードを整理するための手段にすぎない。典型的なレイヤーはプレゼンテーション層、ビジネス層、データ層であり、従来の3-Tierモデルと同じだ。だが、Layerはあくまでもコードの論理的な構成の話だ。これらのLayerが同一マシンの同一プロセスで実行されるのか、異なるマシンで実行されるのかには何も言及しないし、制約もない。

https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/ddd-starter-modelling-process.jpg

サイトの検索導線からも全部見えるようになったようです。 マスタリング・イーサリアム ―スマートコントラクトとDAppの構築 https://www.oreilly.com/library/view/-/9784873118963/ 初めてのGraphQL ―Webサービスを作って学ぶ新世代API https://www.oreilly.com/library/view/-/978487311893