DDD Weekly: Issue #62

Sociotechnical Design Variables [blog] Nick Tune. Looking through the history of my talks and my posts you can see evolutions in my thinking. One of my current working models is that there are five main categories of criteria for designing boundaries: Business Value: design decisions aligned to the business strategy; Domain: design decisions aligning boundaries with the problem domain; Sociopolitical: design decisions driven by the needs of the people building the systems; Technical: design decisions affected by the technical requirements of a system (e.g. performance, security); UX / Brand Perception: design decisions which have an impact on how users experience the system

B-threads: programming in a way that allows for easier changes [blog] Luca Matteis. …our current programming mentality only in part seems to address this demand for easy-adjustment of this artifact we call code. We have developed design patterns, paradigms and higher-level programming languages that make software much easier to maintain; but is it really easier to update?

Online Event Processing: Achieving consistency where distributed transactions have failed [blog] Martin Kleppmann, Alastair R. Beresford, and Boerge Svingen. Support for distributed transactions across heterogeneous storage technologies is either nonexistent or suffers from poor operational and performance characteristics. In contrast, OLEP is increasingly used to provide good performance and strong consistency guarantees in such settings.

Fallacy #1: The network is reliable [blog] David Boike. Compared with a few decades ago, networks are fairly reliable — except for when they’re not. As we continue to build larger and more globally distributed systems, we make ourselves susceptible to all the bad things that can happen… In order to deal with this, we’re going to have to move away from synchronous request/response-type programming. The object-oriented model of invoking a method (known as remote procedure call, or RPC) tends to break down to conditions when the network is unreliable, putting our system into a non-deterministic state that is very difficult to get out of.

Living in eventually consistent reality [video] Bartosz Sypytkowski. Strongly consistent databases are dominating world of software. However, with increasing scale and global availability of our services, many developers often prefer to loose their constraints in favor of an eventual consistency… During this presentation we’ll talk about Conflict-free Replicated Data Types (CRDT) - an eventually-consistent structures, that can be found in many modern day multi-master, geo-distributed databases such as CosmosDB, DynamoDB, Riak, Cassandra or Redis: how do they work and what makes them so interesting choice in highly available systems.

In Pursuit of Production Minimalism [blog] Brandur. Most of us can benefit from architecture that’s a little simpler, a little more conservative, and a little more directed. Only by concertedly building a minimal stack that’s stable and nearly perfectly operable can we maximize our ability to push forward with new products and ideas.

Code Reviews at Google are lightweight and fast [blog] Dr. Michaela Greiler. To sum it up, Google has clear guidelines on what it takes to get a code review approved. What stands between you and the commit to the shared codebase is a review approval from at least one person with code ownership and readability certification. That most reviews only have one reviewer takes also a lot of complexity out of the code review process. Company-wide code styles, make it crystal clear how readable code must look like. This combined with the small code change sizes allows Googlers to expect code review feedback in 1-5hours.

Best Practices for Designing Akka.NET Domain Events and Commands [blog] Aaron Stannard. In this blog post we’re going to cover some best practices you can use when designing domain events and objects intended to work with Akka.NET. If you follow these best practices you’ll run into fewer errors, clearer log messages, and a better extensibility experience.

Event Driven Collaboration [video] Ian Cooper. When we move from a monolith to microservices we abandon integrating via a shared database, as each service must own its own data to allow them it to be autonomous. But now we have a new problem, our data is distributed. What happens if I need one service needs to talk to another about a shared concept such as a product, a hotel room, or an order? Does every service need to have a list of all our users? Who knows what users have permissions to the entities within the micro service? What happens if my REST endpoint needs to include data from a graph that includes other services to make it responsive? And I am not breaking the boundary of my service when all of this data leaves my service boundary in response to a request?