<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Software Architecture on Debimate</title><link>https://debimate.jp/notes/software-architecture/</link><description>Recent content in Software Architecture on Debimate</description><image><title>Debimate</title><url>https://debimate.jp/images/default-ogp.webp</url><link>https://debimate.jp/images/default-ogp.webp</link></image><generator>Hugo -- 0.161.1</generator><language>ja-JP</language><lastBuildDate>Wed, 12 Aug 2026 01:35:39 +0900</lastBuildDate><atom:link href="https://debimate.jp/notes/software-architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Value Object・Entity・Aggregate - DDD のモデル構成要素</title><link>https://debimate.jp/notes/software-architecture/value-object-entity-aggregate/</link><pubDate>Wed, 05 Aug 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/software-architecture/value-object-entity-aggregate/</guid><description>&lt;p&gt;Value Object・Entity・Aggregate（集約）は、DDD（Domain-Driven Design、ドメイン駆動設計）でモデルを組み立てる時の構成要素です。Value Object は属性だけで決まる値、Entity は属性が変わっても同じ物として追跡する対象、Aggregate は不変条件を守るために、その 2 つをまとめた境界を指します。&lt;/p&gt;</description></item><item><title>Bounded Context - モデルが通用する範囲を区切る</title><link>https://debimate.jp/notes/software-architecture/bounded-context/</link><pubDate>Thu, 06 Aug 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/software-architecture/bounded-context/</guid><description>&lt;p&gt;Bounded Context（境界づけられたコンテキスト）とは、あるモデルが定義され、そのまま適用できる範囲を明示した境界です。&lt;a href="https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf"&gt;Evans 氏の DDD Reference&lt;/a&gt; は「特定のモデルが定義され適用される境界の記述であり、多くはサブシステム、または特定のチームの担当範囲にあたる」と定義しています。ここでのモデルは、業務の概念を表す型と、その概念が守る規則の集まりを指します。境界の中では「注文」という語が 1 つの意味に定まり、境界の外へ出た時、同じ語が同じ意味だとは仮定しません。&lt;/p&gt;</description></item><item><title>Repository - Aggregate の永続化を隠す境界</title><link>https://debimate.jp/notes/software-architecture/repository/</link><pubDate>Thu, 06 Aug 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/software-architecture/repository/</guid><description>&lt;p&gt;Repository とは、Aggregate（集約）を 1 つの単位として保存・復元する仕組みで、呼び出す側からはメモリ上のコレクションのように見えます。Eric Evans 氏の &lt;a href="https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf"&gt;DDD Reference&lt;/a&gt; は、DDD（Domain-Driven Design、ドメイン駆動設計）の Repository を「ユビキタス言語で表現された、集約への問い合わせ手段」と要約しています。ユビキタス言語とは、&lt;a href="../bounded-context/"&gt;Bounded Context&lt;/a&gt; の中の全員が会話・図・コードで同じ意味で使う語彙です。&lt;/p&gt;</description></item><item><title>Domain Event - ドメインで起きた事実を伝える</title><link>https://debimate.jp/notes/software-architecture/domain-event/</link><pubDate>Fri, 07 Aug 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/software-architecture/domain-event/</guid><description>&lt;p&gt;Domain Event とは、ドメインの中で既に起きた出来事を表すオブジェクトです。過去の記録なので通常は不変で、出来事が起きた時刻と、関与したエンティティの識別子を持ちます。ここでは、1 つの &lt;a href="../bounded-context/"&gt;Bounded Context&lt;/a&gt; の中で &lt;a href="../value-object-entity-aggregate/"&gt;Aggregate&lt;/a&gt; 同士を繋ぐ用途と、Bounded Context をまたいで他のシステムへ伝える用途を扱います。&lt;/p&gt;</description></item><item><title>Sidecar - アプリケーションへ機能を足す補助コンテナ</title><link>https://debimate.jp/notes/software-architecture/sidecar/</link><pubDate>Sat, 08 Aug 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/software-architecture/sidecar/</guid><description>&lt;p&gt;Sidecar とは、主となるアプリケーションのコンテナと同じ実行単位へ一緒に配置し、そのアプリケーションへ機能を足す補助コンテナです。ログの転送・設定の取得・通信の暗号化のような、業務ロジックと直交する処理を担当します。ここで言う実行単位とは、同じマシンへまとめて配置され、まとめて作られ削除されるコンテナの集まりを指します。&lt;/p&gt;</description></item><item><title>Ambassador - 外部との通信を仲介する補助コンテナ</title><link>https://debimate.jp/notes/software-architecture/ambassador/</link><pubDate>Sat, 08 Aug 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/software-architecture/ambassador/</guid><description>&lt;p&gt;Ambassador とは、アプリケーションのコンテナと同じ実行単位へ配置し、外部との通信を代わりに引き受ける補助コンテナです。通信を代わりに受け取って転送する物をプロキシと呼び、Ambassador はその 1 つです。例えばアプリケーションから外へ接続する構成では、アプリケーションは localhost の 1 つの宛先へ話し、実際の接続先が何台あるのか、どれへ振り分けるのかは Ambassador が判断します。&lt;/p&gt;</description></item><item><title>Adapter - アプリケーションの出力を外向きに揃える補助コンテナ</title><link>https://debimate.jp/notes/software-architecture/adapter/</link><pubDate>Sat, 08 Aug 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/software-architecture/adapter/</guid><description>&lt;p&gt;Adapter とは、アプリケーションと同じ実行単位へ配置し、外から見える出力とインターフェースを統一する補助コンテナです。アプリケーションのコードには手を入れず、外から見た形だけを揃えます。&lt;/p&gt;</description></item><item><title>Anticorruption Layer - 上流のモデルを自分の語へ翻訳する</title><link>https://debimate.jp/notes/software-architecture/anti-corruption-layer/</link><pubDate>Sat, 08 Aug 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/software-architecture/anti-corruption-layer/</guid><description>&lt;p&gt;Anticorruption Layer（腐敗防止層）とは、他のシステムを利用する下流が自分の責任で置く隔離層で、相手のモデルを自分のドメインモデルの語へ翻訳します。&lt;a href="https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf"&gt;Evans 氏の DDD Reference&lt;/a&gt; は「下流のクライアントとして、上流のシステムの機能を自分自身のドメインモデルの言葉で自分のシステムへ提供する隔離層を作れ」と述べ、ACL は相手の既存のインターフェース越しに通信するため、相手のシステムへの変更をほとんど、あるいは全く必要としないとしています。&lt;/p&gt;</description></item><item><title>Event Sourcing - 出来事の並びを一次記録にする</title><link>https://debimate.jp/notes/software-architecture/event-sourcing/</link><pubDate>Mon, 10 Aug 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/software-architecture/event-sourcing/</guid><description>&lt;p&gt;Event Sourcing とは、アプリケーションの現在の状態ではなく、状態を変えた出来事の並びを永続化し、状態はその再生で復元する方式です。Martin Fowler 氏の &lt;a href="https://martinfowler.com/eaaDev/EventSourcing.html"&gt;Event Sourcing&lt;/a&gt; は、この方式を「アプリケーションの状態への全ての変更をイベントの列として記録する」と要約しています。&lt;/p&gt;</description></item><item><title>CQRS - コマンドとクエリの分離</title><link>https://debimate.jp/notes/software-architecture/cqrs/</link><pubDate>Mon, 10 Aug 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/software-architecture/cqrs/</guid><description>&lt;p&gt;CQRS（Command Query Responsibility Segregation、コマンドとクエリの責務分離）とは、情報の更新に使うモデルと、読み取りに使うモデルを分けられるという考え方です。Martin Fowler 氏の &lt;a href="https://martinfowler.com/bliki/CQRS.html"&gt;CQRS&lt;/a&gt; は、Greg Young 氏の説明で初めて知ったパターンとしてこの考え方を紹介し、中心にある発想を「情報の更新には、読み取りに使うモデルとは別のモデルを使える」と要約しています。&lt;/p&gt;</description></item></channel></rss>