Just Googled it. Looks like there's been a lot of legwork already done by other Flutter devs. You could just examine what they've defined and see if that helps you.
Discussion
🫡
That + nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9 + public documentation towards you guys should do it!
Yes to domain centric design and basic separation of concerns, no to premature optimization and overkill like clean architecture for smaller projects where the boilerplate and indirection make up a lot of the code
Choose names wisely and be clear and consistent. Make code expressive and self documenting.
some time ago I wrote some of what I consider good code recommendations nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q
note1y9hfddyw2xrt3l50n9pystcc6qn8q5wl3tkg4aa9xky2hvqharkqhdk80q
Yes, I like that!
TDD is 🤌
i am always writing tests because i very often mess things up and do a lot of encodings, but i haven't yet wrapped my head around this BDD style and other protocol correctness
to me part of the problems start before you even get to writing tests, with a protocol that is unclear or breaks domain boundaries or mixes concerns or creates ambiguities, especially ones that are likely to trigger a human to misunderstand even when the logs are printed out ad nauseum
We're solving the protocol issue, slowly. As long as that progresses, I'm okay with it being a bit messy.
Messy implementations are another thing because they send out corrupted events and burn the Nostr brand.
I have never seen Nostr "smaller projects" not become the basis for the Nostr "larger projects". Even major rewrites don't help, for long, as the regressions immediately begin seeping in, and the entire architecture groans under the weight of its own inefficiency and ineffectiveness.
The crappy quality they begin with just stays that way, indefinitely, because those developers refuse to learn better engineering and are actively discouraged from doing so, by people who pay them to stay ignorant and amateurish, so that they can't steal the limelight from the Planned Winner.
It's worth slowing down, refactoring, and retesting as soon as you notice an architectural flaw. The early stages of the project is the best time to do that, because the more code you have, the more time, energy, and risk is required to fix a bad design pattern.