[B! ドメイン][ドメインモデル] okyawaのブックマーク

okyawa id:okyawa

ドメインとドメインモデルに関するokyawaのブックマーク (2)

DDDのエンティティはイミュータブルな実装にしてもいいの？(サンプルコード有り)[ドメイン駆動設計 / DDD] - little hands' lab
本記事はドメイン駆動設計（ＤＤＤ） Advent Calendar 2021の13日目の記事です。エンティティとイミュータブル性オブジェクトをイミュータブル、つまり内部状態を変えない実装にすることで可読性やマルチスレッド対応性が向上することがあります。エンティティはモデリング上の定義はミュータブルなものですが、実装方法をイミュータブルにすることは可能です。 (DDDでは、エンティティはミュータブルもしくはイミュータブル、値オブジェクトは必ずイミュータブルという定義です。詳しくはこちら) DDD基礎解説：Entity、ValueObjectってなんなんだ - little hands' lab 本記事ではエンティティをイミュータブルな実装にするサンプルコードと合わせて、イミュータブルにした場合の旨みを感じられるコードを紹介します。イミュータブルなエンティティ実装の例エンティティをイ
okyawa 2021/12/14
DDD

ドメイン

ドメイン駆動設計

architecture

domain

entity

エンティティ

イミュータブル

ドメインモデル
リンク
ドメインモデルとは(「現場で役立つシステム設計の原則」より) - Qiita
業務で扱う(最小)単位でデータとロジックをひとまとめにして整理する技法ドメインモデルが実現する世界どこに何のロジックが書いてあるか、(ソースを見るだけで)わかる改修しやすいプログラムドメインモデルで解決したい問題どこに何のロジックが書いてあるかわからない問題 - わからないから適当に書く→適当に書くからわからない → わからないから・・・ - ある修正をしようと思っても、どこまでが影響範囲かわからない - 使用している箇所全grepして調査 - 同じような処理、分岐が重複してしまうこれを解決したい。これだけを考える。なぜ(今までのシステムは)改修は難しいのか機能クラスと、データクラスをわけてしまうからそのデータクラスを呼べる箇所 = 業務ロジックがかけてしまうどこになにが書いてあるかわからなくなる共通クラス、Utilクラスを作ってしまうから誰でも呼べる = そのクラ
okyawa 2019/11/13
ドメインモデル

ドメイン

設計
リンク
1