A change to one source should be easy to locate and review. As BatScrape’s Actor code takes shape, we want its structure to make that possible.
This article describes a proposed organization, rather than an incident history or a set of controls already running across a production platform.
Decide what belongs to the source
Pagination, selectors, and source-specific field extraction usually need the context of that source. Keeping those decisions together helps explain why a change was made and which output it affects.
Shared helpers should have a clear purpose. Reusing a timestamp formatter is a different decision from forcing two unrelated pagination systems through one interface.
Explain each boundary
A short note beside a module can state what it owns, what it may import, and why the separation matters. The explanation is more useful when it describes a concrete failure the boundary is intended to prevent.
Check the checks
If an automated rule enforces a boundary, include an isolated example that should violate it. Confirm that the rule catches the example as well as accepting the real code.
We’ll refine these choices while building the first Actors. The goal is code that is easy to reason about when a source changes, without claiming that any folder structure can eliminate failures.
BatScrape Team
Building BatScrape
