That was a neat talk. Thanks for mentioning the Python eventsourcing library. The Python eventsourcing library which Piotr mentioned (and encouraged people to check out) is here: github.com/pyeventsourcing/eventsourcing As Piotr said, "it is absolutely a great learning resource". The project's Slack workspace (which Piotr mentioned) hosts a friendly and supportive community. People are welcome to join. The library does indeed support "pluggable databases" (as the host asked). There is support in the core library for PostgreSQL and SQLite. There are also extension packages for Django ORM and SQLAlchemy, allowing a greater range of databases to be used. We are also currently rebuilding the adapter for Axon Server and DynamoDB, and also building adapters for EventStoreDB and Mongo. Any suitable databases can be easily adapted. I would like respectfully to disagree with Piotr on a couple of minor points. (1) The library is not somehow "completely incompatible" with EventStoreDB. There is a friendly relationship between the two projects. A Python adaptor for EventStoreDB is forthcoming, and close integration with the library will be available soon. (2) The library is not really "a research project" but rather emerged directly from professional projects. The reason for creating an open source library was to accumulate learning and working code, primarily (a) to avoid creating a series of half-baked code in proprietary repositories and (b) to avoid delaying starting new projects by spending time rolling up a new expression of the same mechanisms each time. As the library was exposed to a greater number of projects, so it was gradually refined. As others began to use it, so the documentation was developed to make it easier for others. The result is a well-factored and easy to use library that makes it relatively easy to succeed with event sourcing in Python. The library has been used around the world and across a range of industry sectors and businesses types (start-ups, SMEs, and large corporations including "Big Tech" FAANG companies) to successfully develop event-sourced applications. It's definitely a viable option for use in production. (3) The opinion "don't use a framework" is really just an opinion. I respect this view. However, one of the common descriptions of event sourcing is that it is a persistence mechanism for domain-driven design. The book Domain-Driven Design has a pattern called "cohesive mechanism". It is perfectly reasonable to apply the pattern "cohesive mechanism" to the pattern "event sourcing" and "partition a conceptually cohesive mechanism into a separate lightweight framework" as Eric Evans suggested in his book. An open source library takes this a step further. The simplest conception of event sourcing is that it is so simple you can just do it with one line of code (a "fold"). In practice, the story isn't so simple. There are several aspects and quite a few subtleties. It isn't just a simple thing to develop an event-sourced domain model that concisely expresses the business concerns, whilst hiding all the complexity, being reliable and maintainable, and performing well. Simple presentations avoid most of the issues that arise when you try to make event sourcing work in practice. The Python eventsourcing library is an open source library that offers firstly the opportunity to learn (the first freedom of free software), but it also offers a selection of well-factored and well-tested modules that can be used to develop event-sourced applications. It's more of a "library" than a "framework" in that you can use as much or as little as you want. Of course, like anything else, you don't have to use a library or a framework. And some people prefer not doing so. But the library offers a well-trodden path to developing event-sourced applications. And the documentation, whilst not perfect, is a good resource for getting started. eventsourcing.readthedocs.io/
John, I browse the Internet in my search of a good example of your spectacular library with CQRS, preferably in Redis. This research has led me to this video where I've noticed your comment. Would you have any hint how to approach this problem? As mentioned by Piotr, how to search aggregates by various properties? If there is an example that you are aware of, that would be great. Thanks.
That was a neat talk. Thanks for mentioning the Python eventsourcing library.
The Python eventsourcing library which Piotr mentioned (and encouraged people to check out) is here:
github.com/pyeventsourcing/eventsourcing
As Piotr said, "it is absolutely a great learning resource". The project's Slack workspace (which Piotr mentioned) hosts a friendly and supportive community. People are welcome to join.
The library does indeed support "pluggable databases" (as the host asked). There is support in the core library for PostgreSQL and SQLite. There are also extension packages for Django ORM and SQLAlchemy, allowing a greater range of databases to be used. We are also currently rebuilding the adapter for Axon Server and DynamoDB, and also building adapters for EventStoreDB and Mongo. Any suitable databases can be easily adapted.
I would like respectfully to disagree with Piotr on a couple of minor points.
(1) The library is not somehow "completely incompatible" with EventStoreDB. There is a friendly relationship between the two projects. A Python adaptor for EventStoreDB is forthcoming, and close integration with the library will be available soon.
(2) The library is not really "a research project" but rather emerged directly from professional projects. The reason for creating an open source library was to accumulate learning and working code, primarily (a) to avoid creating a series of half-baked code in proprietary repositories and (b) to avoid delaying starting new projects by spending time rolling up a new expression of the same mechanisms each time. As the library was exposed to a greater number of projects, so it was gradually refined. As others began to use it, so the documentation was developed to make it easier for others. The result is a well-factored and easy to use library that makes it relatively easy to succeed with event sourcing in Python. The library has been used around the world and across a range of industry sectors and businesses types (start-ups, SMEs, and large corporations including "Big Tech" FAANG companies) to successfully develop event-sourced applications. It's definitely a viable option for use in production.
(3) The opinion "don't use a framework" is really just an opinion. I respect this view. However, one of the common descriptions of event sourcing is that it is a persistence mechanism for domain-driven design. The book Domain-Driven Design has a pattern called "cohesive mechanism". It is perfectly reasonable to apply the pattern "cohesive mechanism" to the pattern "event sourcing" and "partition a conceptually cohesive mechanism into a separate lightweight framework" as Eric Evans suggested in his book. An open source library takes this a step further. The simplest conception of event sourcing is that it is so simple you can just do it with one line of code (a "fold"). In practice, the story isn't so simple. There are several aspects and quite a few subtleties. It isn't just a simple thing to develop an event-sourced domain model that concisely expresses the business concerns, whilst hiding all the complexity, being reliable and maintainable, and performing well. Simple presentations avoid most of the issues that arise when you try to make event sourcing work in practice. The Python eventsourcing library is an open source library that offers firstly the opportunity to learn (the first freedom of free software), but it also offers a selection of well-factored and well-tested modules that can be used to develop event-sourced applications. It's more of a "library" than a "framework" in that you can use as much or as little as you want. Of course, like anything else, you don't have to use a library or a framework. And some people prefer not doing so. But the library offers a well-trodden path to developing event-sourced applications. And the documentation, whilst not perfect, is a good resource for getting started.
eventsourcing.readthedocs.io/
John, I browse the Internet in my search of a good example of your spectacular library with CQRS, preferably in Redis. This research has led me to this video where I've noticed your comment. Would you have any hint how to approach this problem? As mentioned by Piotr, how to search aggregates by various properties? If there is an example that you are aware of, that would be great. Thanks.