module
モジュール (module)： 実装の詳細を外部に漏らさないための抽象化の単位．有限個のメンバ (member) と呼ばれる内容からなり，各メンバは函数だったり，型だったり，或いは入れ子のモジュールだったりする．モジュールはメンバのうち一部の存在を非公開にしたり，型のメンバの定義を抽象化して外部に提供したりする．ref 多くの言語は「module」と呼んでいるが、Goでは「package」と呼ぶものがそれ
モジュールの 概念はソフトウェアアーキテクチャの世界では一般的であるものの、その定義は曖昧だ。 インター ネットで検索すると、何十もの定義が見つかるだろう。しかし、それらに一貫性はないし、矛盾しているものさえある。
本書におけるアーキテクチャについての議論では、クラスや関数をはじめとする、 関連するコー ドのグループ化を表す一般的な用語として、モジュールという用語を使用する。 モジュールは、物理的な分離を意味せず、 論理的な分離のみを意味する。
モジュールはインターフェースと実装を持つコードの任意の単位
モジュラーデザインの目標は、モジュール間の依存関係を最小限にすること
インターフェースが実装よりもはるかにシンプルなものであると良い
シンプルなインターフェースは、システムの残りの部分に課される複雑さを最小限にする
モジュールがそのインターフェースを変更しない方法で修正された場合、他のモジュールはその修正の影響を受けない
指標が欲しい
どういう指標で同じmoduleにまとめて
何を公開するのか
逆に、外部moduleをimportする際の工夫などはあるか
Entityのmodule設計と、Usecaseのmodule設計はまた全然違う感じになりそうな気がする
つまり考える順序が逆
ということは、今mrsekut.iconが知りたいのはEntityのmoduleの作り方だなたぶん
この辺の話はOOPでやると雑になる印象があるmrsekut.icon
classがどでかいので。
いや、知らんけど
上手くやる方法はあるかも知れないが、なんかノイズが多すぎる
型と関数の組み合わせとしては以下の3パターンがあります：
これはちょっとF#固有といった感じもするmrsekut.icon
Haskellとかだと、directoryごとに公開できる範囲を指定したいんだけど、無理なのかな
Post
Type
Parser
Test
Main
のようにあった時、Type内で定義したものを、Post以下では全公開したい
けど、Postの外には公開させたくない
これみたいにしたらいいんかな？
ゆーざーにはHooks.pursから読み込んでもらうようにする
ほかからも読み込もうと思えばできるけど、基本的にはソレはしないという運用
みたいな
Barrelも同じようなものだもんなmrsekut.icon TypeScript
Hoge型からPiyo型に変換する関数は、どのmoduleに置くべきなのか？
Hoge module?
Piyo Module?
Project全体で見た時により重要な方に置くだろう
Piyoの方が重要なら、PiyoにtoHoge、fromHogeを置く
PiyoがDomain Modelなら、Piyoの方が重要だろう
同じぐらいならどうだろう？
お互いに、fromXXXを置くとか？
かなり独立しているものなら、お互いにtoXXXとfromXXXを置くとか？
冗長だけど
Elm、2000行のコードを1fileに収める
わけることでそもそもどういう問題が起きるのか？
このコードはどこに置けばいい？と迷うこと？
迷いを消すために全て1つのところに置くのが正解7日？mrsekut.icon