Discussion on clean code best practice about eventsourcing

[poltronSuperstar]

Does that make sense ?

Actually, I did not see that aspect, but I think I prefer your way now :) .

I missed the fact there was a Slack workspace. I think it's more appropriate to discuss contributions there than in a Github issue, see you there :)

[johnbywater]

Firstly, thanks for asking the original question :) I suppose the reason I had for defining these strings as class attributes is to collect the list of environment variables which a factory is sensitive to. Then I can just look at the top of the class and see, rather than looking through the code. Does that make sense?

Secondly, thank you for your enthusiasm about the lib. I'm really very grateful for it, it means a lot to hear you say you love it. I've spent a long time using and developing it over the past few years, and have just tried to make something that makes sense to other people too. So it's really good to hear you say you like it.

Regarding making further contribution: Apart from stuff that just needs finishing or adding in the core library, things like the changes you submitted yesterday, and other stuff that hasn't been spotted yet, there's the documentation for the system and examples that I haven't finished yet. I'm sure there are still many things that could be improved, but I'm not sure there are lots of big things that need to be added. Perhaps one area that I do think might be usefully improved is support for versioning of models, and perhaps validation of a model against a schema model of a domain model that has been stored in a database, so that you get told when you aren't supporting event schema that was previously deployed. Also better exceptions for common errors to guides users of the library when starting, in case errors aren't very useful. I tried to do some of that, but I think there's still many things that could be improved about the experience you have when you get it wrong (which is easy to do).
Other considerations include a more formal or mature approach or commitment to long term support ("LTS") for particular versions.

Moving beyond the scope of the core library, there's a LOT of stuff which was dropped in v9, that v8 supported: for example MySQL, SQLAlchemy, Django, DynamoDB, AxonDB, gRPC. Then there's other stuff such as EventStoreDB, other cloud native databases. Other system runners, Kubernetes, serverless. etc. The list is really endless... We had a little community meeting a few weeks ago about this, and decided we want to add all this stuff again, but to create separate repositories within a GitHub "organisation" for the project, rather than adding everything into the core library, as it was in v8. All those additions made the project a bit too big, too cumbersome for maintaining the core functionality, less approachable for developers and maintainers, with lots of optional dependencies on databases and other stuff that most likely were never going to be used together. If you want to contribute your ideas and enthusiasm to that general flow, that would be amazing.

Would you like to join the Slack workspace if you haven't already, and speak up about what you want to do? I'm sure people would be very interested to hear from you. I would be more that happy to arrange a Zoom session or other face-face meeting if you wanted to chat about things... just let me know?