So far, we came up with the idea of digitalizing our white boards, we shaped and modelled our domain using domain-driven design, turned this domain into a realtime API, and wrote a client application that talks to our API. In this final episode of our blog series about wolkenkit we want to summarize our experience, share the source code, and present a few things we’ve learned. We have been able to gather some insights and observations on our journey, starting from the first modeling workshop to actually deploying our wolkenkit application to a machine on Digital Ocean.
With most of our team members being frontend people, we were quite happy about the fact that wolkenkit has opinions. It guided us with an opinionated architecture for backend development and allowed us to focus on our actual core domain instead of thinking about infrastructure. It is more important to us is that this architecture is not bound to a particular cloud provider. Especially since cloud computing is becoming more and more monoplized it is crucial to stay agile and to be able to move our applications between different providers.
We truly believe that events are the building blocks for connected business models. The architectural approach used by wolkenkit treats events as first-class citizens. Events and therefore the reasons for state changes in your domain become a crucial part of your design process. Later on, these events are a great starting point for integrating your application with other systems. The event-driven API you get for free makes it easy to listen to them in realtime.
Domain-driven design (DDD) isn’t just a methodology for IT specialists, it is a great tool for learning about your product as early as possible in your project. More importantly, it is a tool to learn collaboratively with important stakeholders involved. Once translated into code using wolkenkit, you will get a real-time API with minimal effort that can then be picked up, verified, and tested by different parts of the team.
Especially designers are often quite familiar with “thinking in DDD” as compared to developers who are usually more focused on data and CRUD operations. So, you might need some moderation when starting off DDD workshops with your team. An experienced moderator can usually keep everybody on track or you can follow some simple guidelines that Susanna from the native web recently outlined. Either way it is important that the whole team supports and embraces the idea of discussing and learning about the problem domain together.
In recent years the frontend world has seen some tremendous innovation. As clients become more and more capable, their architecture becomes more and more sophisticated. That’s why patterns used by wolkenkit have also found their way into the world of large scale frontend applications. Projects like redux are basically CQRS and EventSourcing for the client.
„It’s like redux for the server.”
And that is fantatsic because most frontend developers are quite familiar with these kind of patterns and can be onboarded easily. Nevertheless, the diverging naming conventions between client and server implementations is is definitely challenging. It takes some time to figure out the subtle differences.
One thing to keep in mind while applying this approach is that it is very easy to fall into the trap of perfectionism. With many stakeholders involved you often want to iterate until everybody is satisfied with the model you have built together. However, there is no perfect model, so don’t loose yourself in perfectionism. Come up with different variations and evaluate their tradeoffs and benefits. The wolkenkit-console is a great tool for testing and evaluating a model quickly. The insights you gain from these quick tests can then be taken back to the whiteboard and will also influence business and UX decisions.
Two important features we used in our application haven’t been covered in detail in this series yet. But I’d like to mention them here since they assisted us in building our application more quickly.
Authentication and authorization are two requirements that are important to nearly every application that runs publicly. The groundwork to deal with these issues is built into the core of wolkenkit. There is a very detailed article over at the Auth0 blog that summarizes how to set up authentication for a wolkenkit application. You can also have a look at docs.wolkenkit.io to get more details on how to configure your app, authorize the write model, authorize the read model, and adjust the client accordingly.
Under the hood, wolkenkit takes advantage of well-established standards to handle authentication such as OpenID Connect and JSON Web Tokens. So if you already use an identity provider that supports these standards, you can utilize it to authenticate clients against wolkenkit applications. In our case we use Auth0 since it’s easy to setup and focused on doing one thing well.
Another feature we take advantage of in our application are workflows. We use them to trigger interactions between different parts of our model. They are actually triggered by events inside our domain and can send back commands to other parts of our model or even trigger external services. In domain-driven design this kind of behaviour is often referred to as sagas or process managers. In wolkenkit, this feature is called flows.
Flows can be simple and stateless „if-this-then-that“ rules. For example, when a post is noted, a flow takes care of actually pinning it to a board. But flows can also be stateful and long-running, for example we introduced a very basic tip of the day rule that adds tips to a board depending on how many posts have already been added to it. Think of them as state-machines that can be used to implement complex rules inside your cloud application.
So we started with a prototype and have been using the result internally to structure our Monday meetings since and the result of this approach is a tool that could easily be turned into an actual product.
Along with our friends at the native web, we decided to share the outcomes of this process and release the source code of both backend and frontend under an open license. Check out the repository over at Github if you’d like to dive into the actual implementation details. We hope it will inspire you to build something great.
wolkenkit is more to us than just a tool or a framework. We believe it can be a shared and open infrastructure on which sustainable applications can be built. We are driven by the vision that, in the future, application developers will finally be able to focus on business logic instead of solving infrastructure challenges over and over again. If you share this vision or if you would like to challenge it, get in touch with us! There is an active community slack channel you can get involved in and there’s a detailed documentation you can use to deep-dive into different aspects of building a wolkenkit backend.
Last but not least if you are an application developer or a company that is interested in certain features, simply contact the fine folks over at the native web to become a sponsor or a contributor.