#DomainModelとは
業務上の関心そのもの
- DataStoreから得られたEntityを変換することで生成される
- RepositoryがEntity->DomainModel変換メソッドを持つ
- データの器であるEntityに業務上の「意味」を与える
なぜデータ構造の変換が「意味」を与えることになるのか?
ツリー構造そのものが「意味」なのである
-
XMLがツリー構造でマークアップされて「意味づけられている」とすることを想起せよ
- データ構造は、配列、連想配列、ツリー構造、ネットワーク構造しかない(ハズ)(大まかにはね)
- 連想配列・ツリー構造・ネットワーク構造は、Tableという二次元配列でどちらも表現可能である
- つまり、世の中、二次元配列があれば大抵のものが表現できる
- 配列は二次元配列の特殊な場合と見なせば良い
- つまりデータの器EntityとしてのTableは、非常に適切な構造と言える
- なんでもつっこめる器なのであった
一方で、逆にHTMLがツリー構造なのに、表が表現できていることを見よ
- Tableという二次元配列は、ツリー構造に逆変換できる
- 配列はツリー構造の特殊な場合と見なせば良い
つまり、EntityをTableとして、変換したツリー構造のデータが「意味を持った」DomainModelであると言える
実際、データ変換どうするの?
- JavaScriptは動的な言語なので、byRow()とByColumn()だけでほとんどのことができる
- byRow()
氏名 | 個別月 | 作業時間 |
---|---|---|
Aさん | 2018/09 | 160.00 |
Bさん | 2018/09 | 182.00 |
- これから
[
{
"Aさん": {
"個別月": "2018/09",
"作業時間": 160.00
}
},{
"Bさん": {
"個別月": "2018/09",
"作業時間": 182.00
}
}
] //これができれば良い。深くても同様。
- byColumn()
- 同じく{"氏名": ["Aさん","Bさん"]}など
- 静的型付言語だと、リフレクション機能がないとほぼ無理筋
#まとめ
- データ変換は、SQLこねくり回して最後にbyRow()かbyColumn()でいいよ
- 動的言語でよかった!
全記事
- JavaScriptでクリーンアーキテクチャはどうすればいいのか(前編)
- JavaScriptでクリーンアーキテクチャはどうすればいいのか(Usecase編)
- JavaScriptでクリーンアーキテクチャはどうすればいいのか(Presenter編)
- JavaScriptでクリーンアーキテクチャはどうすればいいのか(initializer編)
- JavaScriptでクリーンアーキテクチャはどうすればいいのか(Repository編)
- JavaScriptでクリーンアーキテクチャはどうすればいいのか(DataStore編)
- JavaScriptでクリーンアーキテクチャはどうすればいいのか(DomainModel編)