Categories

We design, model, and create software to solve a problem for our customer (this can also be a customer from within the same company). Only when we do so, we focus naturally on solving the happy path and want to deliver that value as soon as possible. The only problem here is that we will always come to a point where we get corner cases or business exceptions, and the question starts to arise, what shall we do? Is it worth the effort to invest in building a solution for this, or can we leave this function out of the system because it is not worth it? To answer these question, we want, if possible, feedback from the system to know this. We can quickly get this feedback making it explicit in the form of a Domain Event during our EventStorming and start monitoring it. This way we can leave the options open until we know what to do.

Arranging a wedding is an exciting time to look forward to, but also comes with a lot of stress, especially when planning for it. For most of us, it will be the first time to plan our wedding, and, at least for me, hopefully, also the last. We can, of course, always hire a party planner (sort of like the domain expert on weddings), but getting married is already expensive enough, and for most of us this is not an option. Besides, there is also the family wishes to take in consideration, and might it just be that sometimes our family can also be domain experts. Let’s face it, they already seen there fair share of weddings, and most of them already have experience getting married themselves. We should consider their wishes and especially take advantage of their knowledge. Well, we can, with EventStorming! (and yes, I am the bridezilla of the two).

Technical design decisions can have a severe impact on companies their communication structure. Conway’s law explains; “Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.” Such is the story also with a microservices architecture. A lot of companies decide to use REST to communicate between bounded contexts and/or services. What can happen is that the services in the bounded context now get dependent on each other. The dependency on finishing a service their process will resolve in cascading failures if a service is down. Cascading failures will reflect on the way organizations communicate between teams. Teams now rely on each other before finishing their process. Dependency between teams can severely disrupt the company to respond better to the fast-changing demands of customers; companies get more entangled than before. To combat getting cascading failures, we must follow the communication structure of the business. We can do this by usingEvent Storming and going events-first.

In my previous post, I discussed why we want to write software with empathy in mind; software that is understandable for peers. For us to create software with empathy in mind, we need to create a shared understanding of the users’ needs; the needs we are trying to satisfy with our software. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help us achieve this. By using Feature Mapping (a technique from BDD) and improving this with Event Storming (a technique from DDD), we can create executable specifications and a model for our business needs at the same time. This way, we can write software and tests that match the shared understanding the business has, which enables us to ship more value faster.

One of the biggest challenges as engineers is to write working software and also keep an extensive documentation. Most engineers hate writing documentation, and after they published documentation on a wiki it will die a lonely death. We want to strive for writing a Living Documentation in an Ubiquitous Language. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help you achieve this. Especially when we start writing code, it is really important for the quality of our software to start with tests describing what your application does. We want to write software with empathy in mind, software that is understandable for peers. While software developers are beginning to use the language of the domain (business language) more in their application code, most tests still contain a lot of technical language.

To be able to show you what Property-based testing (PBT) is, let’s start by grasping the concept of a property in programming languages. Since this is a Java tutorial, I will start with Oracle and their definition of a property in their glossary:

Characteristics of an object that users can set, such as the color of a window.

Property is neither a variable/field or a method; it is something in between which is always true in your context. An example is weight in a postal parcel: this always is greater than zero. In Java the following example implementation would follow: