stackus / ftgogo Goto Github PK

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

A lovely ❤️ project you have created here! I knew about Wild Workouts, but this gives even more detail, fills more blanks. Thank you!

I saw that there are no tests, and this is an example app after all. But one cool concept that is on-topic with the whole DDD theme, is to provide BDD tests and - if possible - formulate them according to the Ubiquitous Language (and understandable for non-technical stakeholders).

Example:

  Feature: Select community member role

    As an organizer who owns and facilitates a community,
    I want to be able to change member roles,
    So that I can select other organizers to facilitate with me.

  Background:
    Given the community is active,
    And the organizer is the community owner.

    # In the MVP community ownership cannot be changed. The
    # creator is the owner.

    Scenario: Change membership role settings
      Given the list of community members,
      And changing members' role settings,
      When I save the role changes,
      Then campaigners can be promoted to organizers,
      And organizers can be demoted to campaigners.

An example project that uses BDD in Go (though for a bit more technical features) is https://github.com/trustbloc/orb

(OT: Another thing very cool to test-drive in Go is functional domains. See Domain Modeling made Functional by Scott Wlaschin)

I found that you re-implemented the route in web_handlers.go, what is the consideration?

//
// The generated Chi server components are not used to construct the server it
// is instead used to verify our web handlers cover the API completely.