The American developer Eric S. Raymond once said that Lisp is a language worth learning even if you never use it. The knowledge gained leads to becoming a generally better developer. It is therefore obvious to take a closer look at the language.
Docker has revolutionized the deployment of applications over the past five years, especially the way applications are distributed in the cloud. The open source system Kubernetes is based on Docker and extends it by adding aspects such as automated container management and scaling.
Since the last episode, the domain-specific code for TodoMVC is complete. However, the technical framework that makes the domain accessible via an API, that persists the domain events, and that scales the application as needed is missing. The open-source-framework wolkenkit solves this problem.
The previous episode introduced the design pattern CQRS, which describes the separation of the writing side from the reading side. This improves the application's structure, and also enables you to scale easily. The price for this is that you need to synchronize both sides, which in turn introduces some side effects.
A few weeks ago Jim Fisher wrote a blog post titled The sorry state of OpenSSL usability, where he complained about how hard it is to use OpenSSL unless you exactly know what you're doing. At least on macOS, there is no help available for OpenSSL, and its defaults are pretty poor, such as creating weak 512 bit RSA keys instead of strong ones.
The development of software is not an end in itself, but should always solve a real, existing problem. A domain, which is the subject of the problem to be solved, must be mapped into code as coherently as possible. Only if the domain with its underlying logic is reproduced correctly in all its facets, the software can achieve what is expected of it.
The previous episode introduced mapping of commands and domain events to semantically meaningful code. Consistency and integrity can be ensured efficiently, and even how to save domain events has been clarified thanks to event sourcing. What about reading the data?
Anyone who models an application with DDD needs an approach to persist data. Of course, a conventional CRUD database can be used for this, but there is a better approach: Event sourcing. How does it work?
While the past episodes have defined commands and domain events and have placed them in a bounded context, the last important concept of DDD is still missing: The aggregate. Usually aggregates are explained as transactional consistency boundaries - but what does that mean?
The result of the previous episode was a definition of the domain events for a to-do list. They are usually caused by actions of the user that express his or her intentions and wishes. How can this be modeled?
The variety of programming languages has been growing rapidly again for some years now. If you want to learn something new and look beyond the boundaries of your daily life, you have to ask yourself which language you will benefit from the most.
Two new versions of Node.js were released on October 31st, 2017. On the one hand there is the new LTS version 8.9.0, and on the other hand there is the new current version 9.0.0. Which of these should be used does not only depend on the features of the respective version.
The first episode explained why CRUD is not the answer to all questions. The largest point of criticism is that its semantics is limited to four verbs: Domain experts and users do not think in terms of CREATE, READ, UPDATE and DELETE. What words do they use instead?
Docker for AWS enables you to set up a Docker Swarm cluster in the cloud without much effort. Since Docker can only be controlled from the local machine, you always have to connect using SSH first. This is annoying and includes a number of drawbacks. How can this be solved better?
The TodoMVC application has become the web's hello world. Although it was originally thought of as a comparison of various UI frameworks, it has meanwhile matured into its own ecosystem. If you want to implement the application on the server-side, then why not use domain-driven design (DDD)?