前回のさいきょうパターンの検証結果

まずは前回のさいきょうパターンですが、会社内の勉強会で実装を進めて行ったところ、少し整理されてこのようになりました。

Entity（図中model）はExternal層で使えるようにImmutable.jsのRecordを使って実装
- ReadOnly、副作用NGという意図
- ○ React+Redux的には使いやすかった
- × mutateメソッドで複製が作れてしまうため、"見るだけ"の意図を突破できちゃった
UseCaseはredux-thunkを用いたThunkActionで実装
- ○ CleanArchitectureを意識しないで作っていた頃に似た形で実装できた
- × Storeの構造に依存してしまった
re-ducks構造が合わなかったので廃止した
- re-ducks構造ではaction/operationはreducerと一対だがここではそうならなかった
selectorは無くならなかった
- Reducerだけでは更新タイミングの違う複数の値を束ねた制御が管理しきれなかった
- Reactコンポーネントからプレゼンテーションロジックを排除するのに大いに役立った
Repository検証しきれず

Good
- 小さめのアプリケーションでは「ビジネスロジックを分離する」という点においては十分な成果を出した
Bad
- そもそもCleanArchitectureは小さめのアプリケーションには冗長
- ビジネスロジック（UseCase）にビュー側で採用したいライブラリ（Redux）が入り込んでいるため、UI刷新などには対応しきれない

新・さいきょう

さらにさいきょうを目指し、下記を踏まえて改訂版を作りました。
試験実装はこちら

Good
- Reduxの立場が明確に
  - ビジネスロジックから抜き出せた！
  - InterfaceAdapter層に収まり、つなぎ役として明確になった（今の所）
  - 将来Reduxをやめたい、という場合にも動きやすそう
- みんな大好きre-ducks構成がはめやすい
Bad
- 今の所見当たらない！？
Think
- UseCaseInteractorはRepositoryを綺麗に分離する場合はクラス＋DI、そうでなければ関数という分けでやれそうか
- この捉え方でInterfaceAdapter層にロジックが入らないようにできるのか

というところで、ご意見、ご感想、マサカリなどなど、コメントお待ちしております！