戦術的DDD基本原則まとめ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DDDを実践し始めてまだ日が浅いので、ドメインモデリング中に 細かい原則がすぐ出てこなくて迷うことがあります。 そこで、「エリック・エヴァンスのドメイン駆動設計」から 第2部「モデル駆動設計の構成要素」を中心に、モデルを表現する各要素（パターン）の 基本原則をまとめてみます。 第5章「ソフトウェアで表現されたモデル」 関連 ENTITIES（エンティティ） VALUE OBJECTS（値オブジェクト） SERVICES（サービス） MODULES（モジュール） 第6章「ドメインオブジェクトのライフサイクル」 AGGREGATES（集約）
結構大事なアグリゲートについてもう少し考えてみる - かとじゅんの技術日誌
ちと、小難しい話になります。DDDの話なんで、 コードで学ぶドメイン駆動設計入門 〜アグリゲート編〜 - じゅんいち☆かとうの技術日誌 でも取り上げたアグリゲートに関する考察です。どうあるべきかはちょっと分かっていません。これを読んでこうしたらよいのでは？と思う方、意見歓迎です。インターネットって一方だと面白くないので議論したいですね。 アグリゲートってライフサイクルの境界を扱うための設計パターンです。ライフサイクルで思い出すのはリポジトリとファクトリ。この二つのオブジェクトが扱うのがアグリゲートです。ライフサイクルは至るところに出てくるので、結構大事で、設計の根幹に影響するオブジェクトのひとつではないかと思います。 アグリゲートは、内部のエンティティやバリューオブジェクトを集約している境界で、その境界はエンティティであり、ルートエンティティと呼ばれる。 グローバルな同一性を持つエンティテ
DDDにおいて、なぜ複数の集約にまたがってトランザクションをかけてはいけないのか（multiple aggregates in one transaction） - pospomeのプログラミング日記
DDDでは 集約 = トランザクション境界 でなければならないので、 複数の集約をまたがるデータの永続化処理は結果整合性になる。 なぜ集約をまたいでトランザクションをかけてはいけないのかというと、 集約で「データの一貫性の境界」を表現するため。 なので、集約同士はデータの一貫性を保証しない = 結果整合性 ということになる。 集約がトランザクション境界ではない場合はどうなるのかというと、「データの一貫性の境界」がドメインレイヤで表現できなくなる。 あるときは 集約A, 集約B が一緒のトランザクションで登録され、 あるときは 集約A, 集約B, 集約C が一緒のトランザクションで登録される、というケースがあると、 「データの一貫性の境界」はアプリケーションレイヤのトランザクション開始から終了までのコードで表現されてしまうので、 それぞれの集約がどの粒度で一貫性を保たれるのかが分からなくなる
ドキュメント指向DBの論理的側面と物理的制約 - DDDと絡めて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事のモチベーション RDB(Relational DataBase)の歴史は長く、ノウハウも蓄積されている。 関係代数という学問もあるなどアカデミックにも研究されており、 国家資格である「データベーススペシャリスト」も、ほとんどこのRDBのことを扱うなど、 RDBは一定の体系が確立した技術と言える。 一方で、2010年ごろより広まったNoSQL、特にドキュメント指向DBに関しては、 当然ながらRDBに比べると未成熟な段階であろう。 また主観だが、NoSQLは、スケーラビリティといった物理的側面にfocusが当たることが多かったので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What's an Aggregate Root?
