JUGG CCC 2013 Spring

当日殴り書きメモ

14:15~ Java Small-Object Programming

はじめに

• 9つのルール、DDDなどを総称してSmall-Objectとしている

S-OPって？

• 小さくつくろう
  • テストしやすさ、可読性
  • Javaの冗長さ
  • FWの定番化
  • DDD、9つのルールなどの出現
• S-OPの実現
  • FWは有効活用する
  • ビジネスロジック、ドメイン部分

APの現状

• FWは安定している（SpringMC、MyBatisなど）
• BLが理解しづらく変更容易性がない。テストしにくい。（1000行、意味不明なクラス名）
• ビジネスの変更への対応 → BLの変更
• システムは変わり続ける

Javaの抱える問題

• オブジェクト指向的でないPGが容易にできてしまう。（C言語チック）
• 冗長な構文（アクセサ、toString、equals、close、try_catch）
• よくある問題：検証処理がちらばる。

S-OPの具体例

• プリミティブ型、Stringはすべてラップする。
  • String code; って誰が桁数知ってるの？
  • Codeクラス。（フィールドクラス）
  • Validationもドメインクラスにはかかず、フィールドクラスにかく。
• フィールドクラスを利用しないデメリット
  • たとえばStringとした場合、修正箇所を探すこともできない。（shohinCode, shohinCd）
  • バリデーション処理が重複。全部直さなきゃいけない。
  • 仕様書がないと、商品コードの仕様がわからない。
• フィールドクラスを利用するメリット
  • 利用方法と仕様がひとめでわかる
  • 検索が楽
  • 修正は常に一箇所
  • 仕様書がなくても保守が楽。
• 不必要なアクセサは記述しない。
  • 不必要なSetterでは？ 不変だったりしない？在庫は減らしたり、増やすものじゃない？
  • 不必要なGetterでは？
• FWを利用する。
  • Lombok
    • アノテーションを利用して冗長な処理を削除
    • Ex：@Dataアノテーション
• 例外やログなど、本質的でない処理はSpringなどのFWに。
  • close, try_catch, log

9つのルールとDDD

• 設計と実装をみなおす9つのルール
  • エクササイズ
• DDD
  • ドメイン層 → フィールドクラス
  • フィールドクラス → ValueObject
  • Employeeクラス → Entity
• DDDやらないといけない？
  • DDDのような考え方は最初から必要。
  • アルゴリズムから考え始めてしまうとだめ。
  • ドメイン分析からしっかりやる。
  • あとからリファクタリングしてもだめ。
• S-OPはトランザクションに不向き？
  • 所謂、入れポン出しポンのBLがないAPに最適
  • 少ないフィールドクラスで実現できる。

自動生成への道

• DDDのモデルからフィールドクラスを自動生成。
• ExcelやテキストベースUMLから。
• SpringWebFlow。