本では 8 章が Flux の章になっていますがサンプルコードは 08 ディレクトリが Clean Architecture になっており 09 ディレクトリが Flux になっています。それ以降の章も本とサンプルコードのディレクトリがずれているようです。

14 章の FluxWithRxSwift, FluxPlusExample をビルドするためまず RxSwift をインストールしようとすると

$ carthage update
*** Fetching iOS_architecture_samplecode
Parse error: expected submodule commit SHA in output of task (ls-tree -z HEAD 15/FluxPlusExample/Carthage/Checkouts/iOS_architecture_samplecode) but encountered: 

となってインストールできません。

環境は
git 2.20.1
carthage 0.32.0
です。

https://github.com/peaks-cc/iOS_architecture_samplecode/blob/master/06/MVPSample/MVPSample/Presenter/RepositoryListPresenter.swift#L20

https://peaks-cc.slack.com/archives/G9E5DDLFM/p1537166975000100?thread_ts=1537163915.000100&cid=G9E5DDLFM

@Danbo-Tanaka
https://github.com/peaks-cc/iOS_architecture_samplecode/blob/master/06/MVPSample/MVPSample/Presenter/RepositoryListPresenter.swift#L20
同じファイルで気になってときがあるので、こちらに投稿させていただきますm(_ _)m

`var numberOfRepositories: Int` で隠蔽するのであれば、 `func repository(at index: Int) -> Repository` にしてしまって、  `var repositories: [Repository]` 自体もP内で完結するようにしてしまった方が良さそうです。

決めていくと良さそうなこと書き残していきます

インタフェースと具体型のネーミング

参考:
業務系のクラスでインタフェイスの実装クラス名に「インタフェイス名+Impl」って名前をつけるのはダサいよね。 - wildcatsの日記
http://d.hatena.ne.jp/wildcats/20061203/1165135539

GitHubのリポジトリ の呼び方

論点:

• 各章のコードでバラバラ
• 8章でデータ層としてのexternal interfaceをRepositoryと言いたいけどそれだと名前空間がかぶる

https://peaks-cc.slack.com/archives/G9E5DDLFM/p1537162141000100?thread_ts=1537155417.000100&cid=G9E5DDLFM

• リポジトリ(名前難しい)には検索したGitHubリポジトリに対しUIで付けるスターの状態(+GitHubリポジトリの内容)を保存するので、GitHubリポジトリリポジ…むむう

Result 型

• Result<T> { case success(T), failure } vs { case success(T), error }
• Result<T> vs Result<T, E: Error> vs Result<T, E>
  • Error型制約いらない説 https://peaks-cc.slack.com/archives/G9E5DDLFM/p1537282853000100

他にも各サンプルコードを横断しながら見て気付いたら追記します

例

takasek:
VCは具体型じゃなくてprotocolとして持とう！

ktanaka117:
DIPの説明を入れるかどうかに寄るので、ちょっと考えていた部分でした。
テストについて触れるなら必須なのですが:thinking_face:

takasek:
やっといて損はない（各章で矛盾が生まれない）とこかなーとは思いましたが、まあ今はそれより初稿なので一旦議論は置きですね！