It’s certainly not intentional 
That said, I’ve read the Evans book a long time (~ 10 years) ago, so it’s possible that some ideas got stuck in my subconsciousness and are still present in my coding style
sasajuric
Author of Elixir In Action
5
josevalim
Creator of Elixir
When Chris and I we were discussing the changes upcoming to Phoenix 1.3 generators, we both agreed that we wouldn’t want to force commands/operations at the module level. Your commands should be functions. So I would rather attempt something such as:
public &MyApp.Accounts.login/2
public &MyApp.Accounts.register/2
private &MyApp.Posts.create/2
private &MyApp.Posts.delete/2
I can easily see functionality being shared between those commands. For example, both create and delete command for posts likely share similar authorization rules. So breaking it at the module level seems to impose the wrong level of granularity.
2
hubertlepicki
OK @josevalim, I think there is some definitions mismatch. In DDD/CQRS we have a command, which has a name, data, possibly also ID and timestamp (depending on implementation), and a command handler.
So a command, quite naturally fit into a module and could be:
%TransferMoney{from: “SOME IBAN”, to: “SOME IBAN”, amount: 1234)
and the command handler will be a function.
BTW: Have a look at this project on GitHub: GitHub - commanded/commanded: Use Commanded to build Elixir CQRS/ES applications · GitHub that is pretty young but I did give it a shot yesterday and it seems to work surprisingly well and has some advanced features.
4
josevalim
Creator of Elixir
kraades
“Actor frameworks such as Akka, Orleans and Erlang OTP are also based on streams of immutable events. However, they are primarily a mechanism for concurrency, less a mechanism for data management. Some actor frameworks do have a distributed component, so you could build a distributed stream processing framework on top of actors. However, it’s worth looking carefully at the fault-tolerance guarantees and failure modes of these systems: many don’t provide durability, for example.”
True for Erlang/Elixir?
Some Erlang/Elixir libraries for Apache Kafka…
https://github.com/kafkaex/kafka_ex
Clients - Apache Kafka - Apache Software Foundation → GitHub - kafka4beam/brod: Apache Kafka client library for Erlang/Elixir · GitHub
0
mkunikow
I would agree that Actor model is type of concurrency model. The higher abstract level are stream processing models.
In Scala word there is streaming frameworks like Akka Streams. There are some discussion that actor model is low level and does not compose well and better is using streaming model.
Which shoe fits you? Comparing Akka Streams, Actors, and Plain Futures.
Actor message passing is the GOTO of concurrency. Compose with futures instead.
For elixir I would say something equivalent is GenStage and Flow
But I have not using it, so maybe somebody can confirm if we can comprare GenStage to stream processing.
PS
I don’t want start any holy war
0
mkunikow
henry-hz
Based on this video and the code posted by the presenter, I published a small boilerplate: GitHub - work-capital/workflow: Functional CQRS Eventsourcing Engine · GitHub , but I admit that the approach used by GitHub - commanded/commanded: Use Commanded to build Elixir CQRS/ES applications · GitHub is more clear and easier to debug and test. My question is Postgre VS Eventstore.
0
peerreynders
f(by) - Conference on Functional Programming 2015-11-28 (Belarus 17:30-18:30)
Event Sourcing is actually just functional code
by Greg Young
This talk will go through the concept of event sourcing and show that at its core its really just functional code. You can implement an event sourced system in Object Oriented code but its really hiding what is happening. Have you seen the logo for event store or the cute little dragon? By the end of this talk you will also understand what they mean.
0