Great talk. A couple of points about 28:00 though. There are 3 adapters presented there: command, event, and database. Most of the time, when I see that, I'd assume it should be "state" instead of "database", and (at least) both "event" and "state/database" are abstractions that assume durability. Further down, the claim that "database" belongs to the "business logic" is questionable. It raises many questions: what kind of database is that (relational, document, KV, graph, etc.)? If we make this assumption, we complicate it to discuss a category of significant tradeoffs on how we implement durability. Reference to Evans' interpretation on the next slide (28:20) doesn't help much, as that (IMO) is a higher-level view, and the primary focus here is to stress ownership boundaries b/w services/domains, and it has little with the inner view on each domain. On the practical side, from (personal) practical experience, pushing the database outside of the core business logic domain is a good thing. It promotes the implementation of business logic in a stateless and functional manner. The database abstractions become simpler, e.g. KV would work just fine for the most of "core business" scenarios. Database abstractions are less likely to leak into business logic, which is often, by far, the main cause of monolith horror stories and subject of many engaging articles and blog posts.
I enjoyed this talk. Didn't actually get the connection between technical side and ethical but still it was good
Great talk. A couple of points about 28:00 though. There are 3 adapters presented there: command, event, and database. Most of the time, when I see that, I'd assume it should be "state" instead of "database", and (at least) both "event" and "state/database" are abstractions that assume durability. Further down, the claim that "database" belongs to the "business logic" is questionable. It raises many questions: what kind of database is that (relational, document, KV, graph, etc.)? If we make this assumption, we complicate it to discuss a category of significant tradeoffs on how we implement durability. Reference to Evans' interpretation on the next slide (28:20) doesn't help much, as that (IMO) is a higher-level view, and the primary focus here is to stress ownership boundaries b/w services/domains, and it has little with the inner view on each domain. On the practical side, from (personal) practical experience, pushing the database outside of the core business logic domain is a good thing. It promotes the implementation of business logic in a stateless and functional manner. The database abstractions become simpler, e.g. KV would work just fine for the most of "core business" scenarios. Database abstractions are less likely to leak into business logic, which is often, by far, the main cause of monolith horror stories and subject of many engaging articles and blog posts.
I like the rant against facebook at the end :)