A Screaming Architecture for iOS Projects
Understand your Context
One of the biggest warning signs in software development, is the use of jargon and acronyms within an organisation.
I worked for a firm in the UK, and they had an acronym for platform tickets. When asked, colleagues didn’t know what this acronym stood for (it really was best not to ask questions in that particular organisation).
This is a trivial example, but imagine that your code lacks such clarity that new Hires need multiple training sessions before their first Pull Request.
You know what, Uncle Bob thinks you should make sure you structure your code well. So how might we do that for iOS Swift code?
The Opportunity
As software increases in size, complexity increases. It becomes harder to tell what the system does, and testability for the system decreases.
Use-case Driven architecture
Your code should be driven by the user’s experience and the user’s journey through your App.
That is, your application should very visibly show the type of system that they are, rather than the programming language or App architecture that you happen to have chosen.
