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

この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

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

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

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

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

社員は退職しても別のイベントデータと関連付けされているので、消せないことが多いでしょう。ただ氏名等個人情報に関わるものは持たないようにしなくてはならないので、サブタイプで区別します。

履歴や世代、データの削除すべてをリレーショナルデータベースだけで扱う方法。実用上はオーバーキルになることも多いと思われるので、あくまでもインデックスを効かせ整合性制約をすごくちゃんとやるとしたらこうなるよ、程度の知識として捉えてください。

多くの人が、1回で最高の命名をしようとする。これは難しく、うまく行くことなんて滅多にない。問題はネーミングというのは設計であるということだ。あらゆるものに収まりの良い場所を与え、正しい抽象化をしなくてはならない。これを最初の1回で完璧にこなせる可能性は低い。だから進化的ネーミングについて話をしよう。

getterとsetterは、クラスをみせかけのデータ構造に変える。で、そのデータ構造は独自のAPIをもつことになる。XとYの属性を持てば、getXとsetX, getYとsetYというように。で、これを使う人はこれらを使って業務をどう組み立てなくてはならないかを学ぶ必要がある。 まぁ、これはまだ良いのだが、データモデリングの観点からいうと、問題を先送りできちゃうことがよりマズいのだ。「Xが変わる可能性があるので、Xをセットできる必要があります。このオブジェクトをインスタンス化した後で変更する必要があるかもしれません。」というように。Xをセットするとして、その変更が業務上何を意味するのか? 全く考えていない。「Xがいつ変更されるのか、またどのような条件下で変更するのかを決めるのは、コードの他の部分に任せるつもりです。」

お気に入り / ページネーション / 検討リスト / カテゴリ毎の件数表示 / Conversation threading / オートログイン / 途中保存 / 予約 / 未読管理 / アンケート

CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。

#翻訳 https://www.scalyr.com/blog/the-10-commandments-of-logging/ CC BY 4.0 @Brice Figureau 1.自分でログの書き出しをしない printfをつかったり、ログエントリを自分でファイルに書き出したり、ログローテションを自分でやったりしてはいけない。運用担当者にお願いして、標準ライブラリやシステムAPIコールを使うようにしよう。そうすれば、実行中のアプリケーションが他のシステムコンポーネントと適切に連携して、特別なシステム設定なしに適切な場所またはネットワークサービスにログを記録できるようになる。 ロギングライブラリを使いたければ、特にJavaの世界にはLog4j, JCL, slf4j, logbackなど多くのものが存在する。私はslf4jとlogbackを組み合わせて使うのが好きだ。とてもパワフルで、設

いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。

このADRをレビューするにあたっては、コンテキストのセクションもよくよく議論すべきで、意思決定が妥当かだけ見ても、「実はコンテキストに誤りやあやふやなところがありA案よりもB案の方が良かった…」みたいなことが発生するし、十分にコンテキストが理解されていない第3者や有識者をまじえてのレビューでは、レビューアに意思決定の構造を理解してもらいにくい、ということもある。

Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ

POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた

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

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

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