Building a Better Banksalad iOS App by Improving Module Structure

The Banksalad iOS chapter is improving the module structure of its project to address a sharp rise in code complexity caused by the growing number of service features. The structure, which was split off from an initial single module, ran into problems as it scaled: the Shared module grew excessively large and introduced unnecessary dependencies.

Splitting the Shared Module and Minimizing Dependencies

The existing Shared module had bloated with ambiguous names like Manager and Helper, including even unused code. To resolve this, unused code was removed, and the module was split into smaller, clearly purposed modules such as Constant, SwiftExtension, and DIContainer. The goal is to minimize dependencies so that each module operates lightly, like an independent app.

Applying the Dependency Inversion Principle

By applying Clean Architecture, the Domain layer and Data layer were separated, but the Data layer's interfaces were located inside the Data module itself, which was expected to cause problems if the communication method changed in the future. To address this, a separate DataInterface module was created to isolate the specifications, and the structure was redesigned so that both the Domain and Data modules depend on this interface.

Restricting Access to Implementations and Introducing DI

Access modifiers for implementations were restricted to within the module, and parts that were previously instantiated directly from outside were changed to use Dependency Injection. Feature extension via inheritance was switched to Composition over Inheritance, removing direct dependencies on implementations. This laid the groundwork for flexibly responding to future changes, such as adopting gRPC or implementing client-side caching.