Hello!
I watched your lecture, I think it was named "The principles of Clean Architecture".
There were many insightful points there. One was that we can and should treat the Web as an I/O device, which I totally agree with. Then there's this second story, where you told us you were developing an application and you had to choose the storage, and you first went for the in-memory implementation, then when you needed the persistence, you went for the in-file storage, and you deffered the database implementation right off the project. I like that idea a lot as well! It means the domain really doesn't depend on the persistence. Briliant!
But my question now is this.
On one hand, If the web is an i/o device, then we could defer that too, right? Work on the domain logic/business logic, use the UI (which we don't know what it will be, can be web, can be cli, can be something else), and then after the domain logic, then we choose that the UI should be Web and we implement it.
On the other hand, we're supposed to be agile. We should not agree to the requirements up front, we should build minimal application, show it to the client, update our requirement based on client feedback, deliver some more features, constantly updating with the clients, updating our requirements based on their feedback, all in short cycles. That's how I understand agile.
Here's the kicker. We can't show the app to the client, if the app doesn't have a UI :o So we must pick SOME UI. Should it be some dumb UI, like you chose in-memory storage, and the later migrate it to Web UI after gathering enough requirements, like you later migrated to file storage? Or should we go with web right away, and only code the domain as-if there was no web? Or maybe these two approaches, defering the decisions and agile are mutually exclusive when it comes to UI. I mean, how can you really defer the UI decision, if we want to demo the app? What's the best call?