Currently the main target/module AppStoreConnectCLI imports all other dependencies. As we move past simple commands into more complex synchronisation it'll be more important to separate our concerns.
💬 Task Description
Separate different concepts into their own modules, namely models and their encodings moving to Model and network calls and transformations moving to Network. This leaves the main target to deal with command line input and translating intent to the correct services to call down to. This also alleviates name collisions
👩🔧 Technical Design Notes
Model
Houses our concept of stored and rendered data for the CLI tool
Includes models structs
Includes information about how to serialise the models in their respective formats
e.g. JSON, CSV, YAML, Tables
As such model will import Yams, SwiftyTextTable and CodableCSV
Network
Takes in input options and translates these to API calls. Translates API models returned from the AppStoreConnectSDK into CLI Models to return to the caller.
Houses extension on Model to initialise them with API data
Should expose functions to return requested CLI Models
Keeps it's reactive implementation internal so that the caller can call it's functions in a blocking manner
Network would import Model, Combine and AppStoreConnect-Swift-SDK
As this is where a lot of the logic is housed there is potential for it to be broken up further. But that could stay internal to the Network module... It's definitely the spot that would need the highest test coverage
Filesystem
Exposes functions to retrieve CLI models or write CLI models from disk
Knows the concept of a sync filesystem setup
e.g. default locations and folder heirarcy
Pulls data from disk turning it into CLI models or writes CLI models to disk in the right (or provided) locations
Filesystem would depend on Model and Files
AppStoreConnectSDK
Takes command line input, validates it and calls the appropriate functions on Network or Filesystem
Owns the concepts that come with the command line
Validates command line input
Has a renderer to output serialised CLI models to stdout and errors to stderr
The entrypoint to the CLI tool would import ArgumentParser, Model, Network and Filesystem
🤝 Relationships
Supersedes the domain layer concept described in #41
❕ Problem Statement
Currently the main target/module
AppStoreConnectCLI
imports all other dependencies. As we move past simple commands into more complex synchronisation it'll be more important to separate our concerns.💬 Task Description
Separate different concepts into their own modules, namely models and their encodings moving to
Model
and network calls and transformations moving toNetwork
. This leaves the main target to deal with command line input and translating intent to the correct services to call down to. This also alleviates name collisions👩🔧 Technical Design Notes
Model
Houses our concept of stored and rendered data for the CLI tool
struct
sAs such model will import
Yams
,SwiftyTextTable
andCodableCSV
Network
Takes in input options and translates these to API calls. Translates API models returned from the AppStoreConnectSDK into CLI Models to return to the caller.
Model
to initialise them with API dataNetwork would import
Model
,Combine
andAppStoreConnect-Swift-SDK
As this is where a lot of the logic is housed there is potential for it to be broken up further. But that could stay internal to the Network module... It's definitely the spot that would need the highest test coverageFilesystem
Exposes functions to retrieve CLI models or write CLI models from disk
Filesystem would depend on
Model
andFiles
AppStoreConnectSDK
Takes command line input, validates it and calls the appropriate functions on
Network
orFilesystem
stdout
and errors tostderr
The entrypoint to the CLI tool would import
ArgumentParser
,Model
,Network
andFilesystem
🤝 Relationships
Supersedes the domain layer concept described in #41