The Core Of Google’s Recommended Flutter Feature DDD App Arch, Event Sourcing

No Flutter GDE seems to understand that to implement Google’s DDD Feature Flutter App Architecture hinted in the Flutter Skeleton App template one has to implement the CQRS-ES set of patterns. CQRS is command query responsibility segregation and the ES part is event sourcing.

This article will cover the event sourcing part, which of course implies reactive events using reactive programming.

The Reactive Programming Core, The App Observable Logger

It is ill-formed myths about antipatterns that can kill the UX responsiveness of our Flutter app, in this case it’s both singletons and event buses. In the case of singleton’s while the use cases of singletons are not as wide when it got introduced as an OOP pattern during C++ heyday; it still can be used for those use cases where it’s an OOP item that we never test in the first place such as app loggers.

In the event bus use cases, it was not the event bus itself that was the actual antipattern, but the fact that they were implemented in non-reactive programming ways that presented bottlenecks in the communication between application components.

And both things implemented in the right avoiding antipatterns way that form the Event Sourcing backbone of both the Command Query Responsibility Segregation (CQRS, which simply means that we separate the crud operations of read and write to be separate, and it’s a command query pattern that acts as input and output to the crud read and write operations) pattern and the full Domain Driven Design Feature architecture that is often nicknamed the vertical slice DDD app architecture pattern due to the fact that the decoupled communication between application layers forms a vertical slice and Google calls it Feature as we can split our areas of application concerns by feature named folders of screens as the communication to the domain is decoupled via the CQRS-ES.

While I do not show this in this example, the observability of the app logger comes from the decoupled appenders we can implement using the logger appenders package as it has four pre-made appenders and infrastructure to manually implement our own appenders to integrate with any 3rd party logging observability service providers we want to integrate with.

So let’s get down to implementing a perfect application logger that has at its core a singleton:

It’s the factory singleton pattern that uses a private constructor, a reference to the private constructor and a factory to implement the singleton, with the initialization being in the factory block. And in the factory initialization block I am setting up the levels that the logger listens to and an actual listener for log events that handles both logging errors and stacktraces and normal log events.

Now we need the other part of event sourcing, the actual event bus that at it’s core uses reacting programming just like this application logger as the internals of the logger class uses streams as evidenced by the way I have declared the listener.

The Event Bus

I modified Andrew’s Event Bus Plus code to integrate with CQRS and that original code is under MIT license copyright of 2021 and the package is here:

Let’s talk about OOP patterns for a moment. We want to pass around events that happened to get logged by the application logger. And at some point integrate those event objects with a command query pattern. That implies that the underlying event objects are in fact value-objects that need to be comparable to each other based on value and not type as a group of events will still have the same run-type, such as app event for example.

So I am going to use the non-code-generation solution of using the package Equatable to create some value objects for the event bus:

Then we have an event bus interface:

Now we need a subscription event handler:

And the event bus itself:

The modifications I made to Andrew’s code was to make it always log using my app logger.

Resources

Resources because no one has the money to go into debt for the private college CS, the private art college degrees, and the psychology degrees that are required to make the human emotional transformative software that this new human emotional world requires.

Chris Do’s Futur YouTube channels

Resources at AIAG

Nielsen Norman Group Articles

Flutter Internals Book

Dart VM Internals

Awesome Psychology List of Resources at GitHub provided by WeeBox

Thoughts

I have no idea why the Google Flutter GDEs are not covering Feature Domain Driven Design app architecture other than they have no freaking idea of what Command Query Responsibility Segregation and Event Sourcing’s role in implementing Feature Domain Driven Design in the first place. The other reason why this is important is that Feature Domain Driven Design with CQRS and ES at its core is the way to in fact implement both SOA and Microservices in a Dart or Flutter application.

Now, onwards to the CQRS part of CQRS-ES core of Feature DDD app architecture.

About Fred(Fredrick) Grott

Look the quality of Flutter GDE’s somewhat sucks, for example this Flutter GDE is recommending avoiding singletons in this article:

And the same Flutter GDE turns around in the same article and recommends a singleton solution to state management which is opposite of what Google recommends! I also find numerous UX design mistakes as well with the same Flutter GDE people. You as a Dart and Flutter App designer and developer deserve better in the quality of Google Dart and Flutter design and developer coverage.

I found after I got control of my ADHD that my ADHD super-powers of focus, seeing connections before others, emotionally wanting my audience to win, and my strong visual organizational and design bias in fact makes me the perfect one to teach both design and software development of Dart and Flutter applications. Your hero arch in Dart and Flutter app design is not won on logic but the actual practice of story-telling until I find the exact right combination of logic, visual, story, etc. to reach all of you about Dart and Flutter app design. Just as this winning you as an audience is emphatically a process, so too is the design of Dart and Flutter Apps, and I am here to win the war of reaching all of you to impart the art of the process of Dart and Flutter App design.

By joining medium (yes, I get a cut of that membership fee which I use to update equipment), you can unlock past the first 3 free articles and get my full stream of my articles AND exclusive to Medium members a free preview of my Flutter Design Book chapters which I am publishing on Medium as an exclusive Medium membership benefit. If, however, you currently do not have the money to invest in a Medium membership I do post the medium free article links on these social media platforms:

YouTube https://www.youtube.com/c/FredGrott

LinkedIn https://www.linkedin.com/in/fredgrottstartupfluttermobileappdesigner/

Instagram https://www.instagram.com/fredgrott/

Twitter https://twitter.com/fredgrott

As I travel on this adventure of starting my own brand story telling studio, I will be publishing some UIKits and books at GumRoad:

https://fredgrott.gumroad.com

And of course I will publish free UIKits on:

GitHub https://github.com/fredgrott

Dribbble https://dribbble.com/FredGrott

BeHance https://www.behance.net/gwsfredgrott