Feedback and ideas

[aschrijver]

Hi @stackus

Love what you are doing with this demo app. Great to see all the BDD feature tests you added. I wanted to post some bits of feedback and some additional ideas that may inspire.

Feedback

Note: This is merely an observation. I don't have deep insight in all the ins and outs, design decision and possible alternative.

Each of the sub-domains / bounded contexts is conveniently packaged in its own Go module. Except that, should I add a command / event etc. there's need to update serviceapis, and the domain is not self-contained but depends on this. In an application I intend to develop there are no microservices, but a plugin architecture based on HashiCorp go-plugin, which would allow dynamic addition of plugins at runtime (e.g. downloaded from a Marketplace of 3rd-party components). The serviceapis setup would not work in my case then, and I feel that in a microservices environment with, say, distributed remote teams working on them, this would be inconvenient too.

Ideas

There is a very interesting addition to DDD/CQRS/ES that may significantly reduce overall complexity, and that is: adding an Actor Model to the design. One of the original devs behind Akka has created a Golang-based actor framework named Proto Actor.

With actors part of the design you can delegate all kinds of complex things, like location transparency, guaranteed message delivery, while increasing the overall resilience of the application. There are basically 2 ways to add to an existing DDD design:

1. DDD Aggregates are actors (Vaughn Vernon's approach)
2. Actors in application layer load, cache and invoke aggregates (Alexey Zimarev 's approach)

The second approach looks most appealing to me. The domain stays fully self-contained, and once you've retrieved / hydrated an aggregate (slow) it is cached within the actor / memory for the next use (fast).

Note that Alexey is involved with proto.actor. In this video he explains his approach.

---

Finally there's an interesting 2-part video that demonstrates Event Storming for an OAuth2 implementation in Go. The event storming is imho a great, maybe obligatory tool at the start and during DDD projects. The DDD process (strategic design) is as important as the resulting code (elaborated via tactical design). It is here where you keep the (non-technical) customer most likely on the same page as the dev team and vice versa.

Maybe there's something interesting on the documentation side you can borrow from these video's, and maybe even the OAuth2 specific example can play a role in ftgogo, idk. Here are the code and videos:

• Code: https://github.com/inklabs/goauth2
• Part 1: OAuth2 Event Modeling in Go
• Part 2: OAuth2 Process Manager