> I read this as the author wanting to decouple as many things as possible Nope. This was actually created incrementally, starting with YAGNI/DTSSTCPW, adding

> I read this as the author wanting to decouple as many things as possible Nope. This was actually created incrementally, starting with YAGNI/DTSSTCPW, adding elements only when they became absolutely necessary and actually removing a lot more code than was added, despite becoming much better in quality and performance. The one big thing was that the additions were not limited to the architectural preconceptions we currently have. And then there was a lot of serendipity. This was not what I had set out to build ... it turned out way better. > risk of the UI flooding It turns out that Blackbird actually prevents that exact scenario, in fact that was the main reason for reifying the update events in the first place. And it worked pretty much perfectly at that. > ... lose techniques for coordinating dependent changes. Not our experience. > Highly decoupled architectures are harder to debug with traditional tooling Might be the case generally, we did not find that to be the case with Blackbird. I think that was largely because the elements were both very simple and so incredibly easy to test individually that we got very few surprises in the composed results. But you can and do, of course, still test the compositions as well. Hexagonal architecture For the Win! > The decoupling introduces a break in the trail, like a fugitive slipping into the river to shake off the bloodhounds. Again, not really, as the model, where the functionality/complexity lives is pretty much exclusively synchronous. The parts at the edges where asynchrony is introduced are generic and largely functionality-free, they tend to not change with new functionality and thus not be the source of new bugs. And of course you can also test them independently. As an example, the code path for performing all requests is completely generic. The only parts that change are the PI to URL translation and object serialisation/deserialization, and those are local, functional and easy to test without all the other machinery. Once that works, the confidence that it will also work with actual requests going over the wire is close to 100%.