クリーンアーキテクチャで値オブジェクトをユースケースのアウトプットに使ってもいいか？

## 疑問だったこと

クリーンアーキテクチャで<font color=orange>Enterprise Business Rules層</font>の値オブジェクトを、<font color="green">Interface Adapter層</font>にアウトプットとして直接渡していいか？

それとも、<font color="red">Application Business Rules層</font>で値オブジェクトの中身をデータストラクチャオブジェクト(図2のOutput Data)に移し替えて<font color="green">Interface Adapter層</font>に渡したほうがいいか？

図1

![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f3239333336382f37636531666231302d353034652d313665302d383933302d3237386238613766393432642e6a706567.jpg](https://qiita-image-store.s3.amazonaws.com/0/889/16c680dc-f1fa-94bd-47c6-7476d83808de.jpeg)

図2

![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f3239333336382f64393037316236392d653665652d366632622d646464642d3630303437303736373062332e6a706567.jpg](https://qiita-image-store.s3.amazonaws.com/0/889/588c865b-2eee-ae11-a576-7f80fe1244af.jpeg)


### 疑問の背景

今回悩んでたのは<font color=orange>Enterprise Business Rules層</font>に値オブジェクトが20個くらいあり、それを<font color="red">Application Business Rules層</font>でデータストラクチャに変換してアウトプットに返すかどうかという点です。実装コードを想像すると、同じコードのクラスがいくつもできてしまう気がして、どちらにするか悩んでました。

値オブジェクトをデータストラクチャに移し替えないと、<font color="green">Interface Adapter層</font>から見たら隠れ層である<font color=orange>Enterprise Business Rules層</font>の変更が間接的に影響をきたすので、アーキテクチャ的には筋が悪いとは感じたのですが、コピペとトレードオフしてもいいのかもやもやしてました。

## 疑問への答え

* 求心方向の依存は絶対守る
* 値オブジェクトをそのまま<font color="green">Interface Adapter層</font>とかに渡るようにするか、データストラクチャにに移し替えて<font color="green">Interface Adapter層</font>に渡るようにするかは、明確なルールはなく決めの問題。(ただし、図から察するに典型的なシナリオでは移し替えることを想定している可能性が大いにある) 

ご回答を下さった @nrslib さんと、 @pospome さん、 @hirodragon さんに感謝。

<blockquote class="twitter-tweet" data-conversation="none" data-lang="ja"><p lang="ja" dir="ltr">以下 Slack より<br>端的にまとめると<br><br>・ボブおじさんが示した典型的なシナリオ（図）では依存していないようにみえる<br>・ただ、依存方向を内向きにするということがコンセプトなので、そもそもレイヤーについてが厳密ではなく、レイヤーを飛び越えて依存したとしても問題ない<br><br>みたいな感じでした <a href="https://t.co/jg3ufJzPBd">pic.twitter.com/jg3ufJzPBd</a></p>&mdash; nrs (@nrslib) <a href="https://twitter.com/nrslib/status/1078146974916927494?ref_src=twsrc%5Etfw">2018年12月27日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">で、&quot;strict layered or relaxed layered&quot; ってこの点を疑問に思うから調べるんだけど、明記されている or いないに関わらず、そのまま使うことによってどういったメリデメがあるかを考えるといい。もしメリデメが明確ではなければ個人の好みであったり、決めの問題なので好きな方を使ってみるといい。 <a href="https://t.co/oZg2APfO8w">https://t.co/oZg2APfO8w</a></p>&mdash; pospome (@pospome) <a href="https://twitter.com/pospome/status/1078134185766748161?ref_src=twsrc%5Etfw">2018年12月27日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">自分も過去に調べたけど、これは「内側に依存する」というだけで明示されてない気がするな。 <a href="https://t.co/cwZ9JUAYOX">https://t.co/cwZ9JUAYOX</a></p>&mdash; pospome (@pospome) <a href="https://twitter.com/pospome/status/1078133694085312512?ref_src=twsrc%5Etfw">2018年12月27日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

## 実際どうするかについてのアイディア

戦略としてはコードの再利用性重視 OR 層の独立性重視かの二択なのだが、それぞれ細かい実践の部分で工夫はできる。

* エンティティに所属する値オブジェクトを公開する (relaxed layered architecture)
    * 値オブジェクト周辺のライフサイクルとデータストラクチャクラス周辺のライフサイクルがほぼ同じ場合など
* 汎用的な値オブジェクト(DateTimeなどと近い存在)をパッケージに切り出して共有する (shared kernel的な)
* 値オブジェクトをデータストラクチャオブジェクトに移し替える (strict layerd architecture)
    * そんなに値オブジェクトの数が無い場合は、手作業で詰替コードを書いてもそんなに辛くない
    * アーキテクチャにもデメテルの法則があると主張できる
    * その際のコードの重複は妥協する
    * データストラクチャクラスをコード生成することで、退屈なコーディングを避ける (code generation)
        * 値の詰替えは退屈な作業になってしまうから
        * 値オブジェクトがたくさんある場合は自動化したほうが楽
        * コード生成後は別々のライフサイクルをたどる
* 方針を確定する前にお試しで実装してみて、どちらがそのプロジェクトに合っているか見極める
    * テストコードまで書いてみる