Meta modern Software Architecture - Neal Ford

Where do architecture styles come from? Do architects retreat to an ivory tower to decide what the Next Big Thing will be? No-new capabilities constantly appear in the software development ecosystem, and clever architects figure out new ways to leverage the new building blocks, leading to new named architecture styles which are only named after they have existed for a while. This is similar to art and cultural movements, how Victorianism became Modernism. In this keynote, Neal traces the similarities between architecture styles and cultural movements, how each affect the other, and points towards how Metamodernism will inform architecture, corporations, and individual workers in a fundamental way.
For more on-demand content, visit: saltmarch.com/on-demand

[@r_mclovin]

I like the rant against facebook at the end :)

[@sergeypichkurov8757]

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.