#DDDConf01

ミノ駆動 @MinoDriven

「コードがダメでもドキュメントがしっかりしてれは大丈夫でしょ？」こういうのも弊社に多い。コードもドキュメントも低品質なクセに。 #DDDConf01

Coward@サヨナラの意味 @FScoward

#DDDConf01 javadocの保守を死守してコメントは書かない

Coward@サヨナラの意味 @FScoward

#DDDConf01 補足はテストクラスで表現

Coward@サヨナラの意味 @FScoward

#DDDConf01 図は必要ですね

uzzu @uzzu

ドメインビジョン声明文は書かないのかな？ #DDDConf01

Coward@サヨナラの意味 @FScoward

#DDDConf01 テストコードをドキュメントとして扱う

ミノ駆動 @MinoDriven

なるべくドキュメントはフライウェイトにするのは賛成。ドキュメントに依存しすぎるとコードは劣化するわ、コード対仕様の莫大な翻訳作業＆翻訳メンテが必要で生産性がガタ落ち #DDDConf01

Okuda @yoskhdia

全体像はモデル図。モデルそれぞれの説明はコードドキュメント。補助はSpec。が一般的な雰囲気。Whyを残すためにマインドマップというのは面白いなー。どれくらい大きくなるのだろう？ #DDDConf01

Coward@サヨナラの意味 @FScoward

#DDDConf01 集約のお話

Okuda @yoskhdia

有用なドキュメントはマニュアルだ、という話もありますね。 #DDDConf01

Coward@サヨナラの意味 @FScoward

#DDDConf01 集約はライフサイクルを同一にするオブジェクトのまとまり

ミノ駆動 @MinoDriven

でも実践DDDの集約クラスでは、メンバがpublicなんだよなー。あれはマズいやり方なんかな。 #DDDConf01

Coward@サヨナラの意味 @FScoward

#DDDConf01 集約の大きさに気をつけなければいけない

Coward@サヨナラの意味 @FScoward

#DDDConf01 境界の定義が重要

Coward@サヨナラの意味 @FScoward

#DDDConf01 境界の定義難しい

Coward@サヨナラの意味 @FScoward

#DDDConf01 集約は整合性を保証する条件

Coward@サヨナラの意味 @FScoward

#DDDConf01 集約の内側では強い整合性を維持、 外側では結果整合になりやすい

Coward@サヨナラの意味 @FScoward

#DDDConf01 ビジネスルールとの折り合い

Coward@サヨナラの意味 @FScoward

#DDDConf01 プロジェクトの初期にやっておいたほうがよい

Coward@サヨナラの意味 @FScoward

#DDDConf01 テーマ: ScalaでのDDDの実践方法

Okuda @yoskhdia

集約をちゃんと設計することが、RepositoryやActorや色々なところでのデータ整合性に寄与する。逆に言えば、早期に整合性を守る境界はどこかを決めたほうが良い。 #DDDConf01

大西　真央 @mmmmao0530

ビジネスルールに即した集約を考えると、巨大な集約になってしまって、いつも悩んでいたけど、ビジネスルールを早めに調整→折り合いをつけて、ビジネスとして集約を小さくすればいいんかー！ #DDDConf01

Coward@サヨナラの意味 @FScoward

#DDDConf01 リポジトリの実装むずい

Coward@サヨナラの意味 @FScoward

#DDDConf01 集約ってどうやってるの？

Coward@サヨナラの意味 @FScoward

#DDDConf01 無限にあるものと有限であるもので分けている