Tired of chasing an elusive architecture and finding good community that helps promote it. Basically:

- Not CRUD
- Not MVC
- More like CQRS; commands and queries represent use cases
- Event Sourced; event log is source of truth, everything else is a cached projection
- Functional Domain Design; not DDD; focus on immutability and simplicity
- Functional in general; less OO
- More focus on domain concepts rather than tech concepts
- Domain can be used through CLI, API, or SDK
- UI is just another client to the API
- Authorization is ABAC, graph-based access control

I'm looking for a fucking unicorn.

@h3ll glad that there are others who think in the same way.

The various concepts are well known, but in isolation. The CQRS/ES community is small but it does exist. The FP and immutability community exists across many languages and frameworks. Reusable domains are basically hexagonal architecture. Where I don't find resources is functional domains and authorization, and of course tying everything together.

I think this tells me that my view of the world is not mainstream, but that it's based on somewhat well defined, but isolated, ideas.

@h3ll I came across lagom in the past but didn't spend time investigating it. I'll check it out.

And don't get me started on microservices. It's a nice idea for some organizations, but I think it's been taken too far.

I value simplicity that results from separating logic from data. Microservices seem to take OO to the extreme where every class is a service.

@h3ll those are nice examples of frameworks or tech that attempt to go into some of the directions i mentioned. What I'm after is not yet another stack. I'm after a design philosophy that accentuates the domain and makes the use cases it's trying to serve prominent, instead of being buried down and eclipsed by what the framework or tech forces you to do.

Yes persistence is always going to be important, but you need to think that, e.g., immutable events is what should be stored, not mutable entities. Now should i use a sql store to store events? Maybe. But it's secondary to the main concept.

The same for the domain itself. DDD favors rich domain models, but i think this makes domain entities complex and may lead you to put logic that serves many use cases in the same object. I favor a functional approach where entities are "anaemic" and they get threaded through functional units, each implementing a separate use case.

(cont) lagom, akka, cassandra, kafka, samza, datomic, etc may help inspire me, but I'm still trying to find the design philosophy and the associated principles and patterns that transcend all those technologies, and bring many of those ideas together. Kind of similar to how relational algebra embodies a way of thinking about and modeling and querying data; then choosing a sql database becomes a secondary concern.

These techniques feel like a more natural way to model and build software. Please let's create a place where we can teach the world to think in FDD, CQRS & ES.

@hasselsoff or at the very least a place to flesh out these ideas ;)

How do you guys feel about Elixir and Erlang for creating these kinds of systems?

@hasselsoff I'll admit that I suck at interacting with the tech and open source community, let alone start an initiative around my ideas. I thought of starting a blog, but I still lack the experience to back my ideas. That's why I'm still in the research phase. Maybe one day.

As for Elixir and Erlang, I've heard some good things, but haven't explored them yet. I guess many devs are suffering from language/framework proliferation fatigue, and I'm no exception.

@h3ll I know we could go on forever, my point was to share my frustration with the devrant community. Thanks for sharing your thoughts.

The primary resources I found were some presentations from Chris Richardson, blog articles from Lev Gorodinski, Jimmy Bogard, and Debasish Ghosh, and of course Greg Young. There's also a google group for CQRS/DDD.

Overall there's a niche community, but it's fragmented and they follow similar but different tracks. I feel if this paradigm will take off, it needs a big force (read: google, microsoft, facebook, etc) behind it, which I don't see happening any time soon. So I'll be over there in my corner trying to figure this out.

Can't believe I haven't seen this before. So refreshing to read, I've been down the CQRS/ES road for almost two years, and I cannot find myself going back towards CRUD.

Devs I've shown this to, all like it, but are afraid of breaking out of the comfort zone. With full audit history and flexibility of migration of models by means of replay events, reports that can be generated from T=0, and continously appended to instead of a 2000 long join query, speak for itself.

Rapid prototyping with CQRS, beautiful.

It does however require a little infrastructure, which is why people stick to the "old" way - even though they will add messaging etc later anyways.

Despite frameworks, I feel CQRS is meant to be more bareboned - framework free. It's a super clean way from function to persistence of events.

Convincing of a more task based UI is also problematic, usually clients always "look and behave like Excel". Grids and huge forms..