Notes from The Architecture and Modeling Learning Event — Vaughn Vernon Signature Series Live in Action

The authors of Vaughn’s book series at Addison Wesley teamed up for a free online conference. “The Architecture and Modeling Learning Event” covered not only software architecture, domain modeling and API design but also business strategy and modeling, product management and loosely coupled messaging. This post summarizes each talk.

Note that these are personal impressions; we do not aim to be complete.

“Domain Storytelling – Understanding Your Users by Drawing Pictures”

What a nice start to the day with stories at the fire pit told by Henning Schwentner! He introduced us to Domain Storytelling, a collaborative modeling technique comprising two main elements:

Domain Storytelling = Pictographic Language + Workshop Format.

The pictographic language is deliberately kept simple (actors-activities-work objects), so it is easy to pick up and one doesn’t get lost in the details of choosing among different arrows and forms of boxes. This simplicity is essential because while the domain experts tell their stories, the listeners (or artists?) draw these pictures on the fly in the workshop, applying active listening to minimize misunderstandings.

“The Idea of Product Architecture”

Steffen Hartmann’s talk was all about product-centricity. Products are a vehicle for value exchange, meaning customers get value (for instance, new capabilities) and companies get money. So thinking about products helps to align the technology with the business side. Product architecture then provides a shared mental model that allows:

1. “The arrangement of the functionality of a product.
2. The mapping from product functionality and features and their connection between each other and to business outcome.
3. The specification of the required dependencies and the interaction between technology and product.”

We learned that this is not a new methodology, nor a roadmap, but rather a high-level representation of what’s important. This representation can serve as a strategic tool and starting point for domain modeling.

“Adaptive Socio-Technical Systems with Architecture for Flow”

Susanne Kaiser asked, “How to design systems that can evolve and thrive in the face of constant change?” She suggested a combination of approaches:

1. Understanding the business landscape, for example with Wardley Maps.
2. Team topologies to align teams for a fast flow of feature deliveries, supported for instance by platform teams.
3. Strategic Domain-Driven Design (DDD), Bounded Contexts in particular to decompose big balls of mud.

This was a highly-paced talk supported by fantastic illustrations — definitely looking forward to the release of Susanne’s book “Adaptive Systems With Domain-Driven Design, Wardley Mapping, and Team Topologies: Architecture for Flow”.

“A Conversation on Continuous Architecture”

Eoin Woods talked about how architecture has become much more fluid and faster evolving in the past decade, with shorter release cycles, clouds, microservices and so on. But how can an overall architecture of a system be maintained without slowing down or blocking autonomously acting teams?

Traditional upfront software architecture might be of less value today, but of course, architecture is still needed, for example, there are overarching quality attributes (security, scalability), stakeholder concerns to balance and complex tradeoffs to make.

“Continuous Architecture” is one of the emerging responses to these challenges.

Continuous means that it’s not a one-off architecture but a stream of decisions.¹

The book’s six “Principles of Continuous Architecture” include:

• Architecting products² and
• Delaying design decisions until absolutely necessary.³

The four other are Focus on quality attributes; Architect for change; Architect for build, test, deploy, and operate; Model the organization of your teams.

“The Impact of Managed Services on Modern Software Architecture”

Joe Emison opened his talk with a slide that read:

There are no continuing education requirements in software development.

You may be wondering, and I certainly was, how this relates to the managed services mentioned in the title of this talk. Joe continued to talk about the impact that managed services have on how we build software. Managed services, for example, serverless offerings such as AWS Lambda or DynamoDB, have the advantage that server operations and preserving the uptime of services are taken care of by the cloud providers. Using managed services, scaling infinitely and never going down can make teams more productive.

The catch is that teams must learn and understand how these new technologies work to take full advantage of them. And that brings us back to the opening slide: Continuing education is essential, even if it is not officially mandated, for instance, by professional associations. Joe’s upcoming book “Serverless As a Game Changer: How to Get the Most Out of the Cloud” teaches us how to use managed cloud services effectively.

“Balancing Coupling in Software Design”

Vlad Khononov’s talk was about coupling. Coupling often has a bad reputation and everybody knows that it’s not good, so we want to decouple everything. For example, we might want to break large things apart into smaller units that can evolve independently. But without any coupling, there are no relationships between individual parts of a system. So what’s essential about (de-)coupling is that it doesn’t prevent us from making the changes that we need.

Coupling defines the relationship between components and limits components’ degrees of freedom.

Vlad continued to present different kinds of coupling, which is the topic of his upcoming book: “Balancing Coupling in Software Design: Successful Software Architecture in General and Distributed Systems”.

Mirko hands over the note-taking to Olaf at this point.

“Designing APIs with Patterns”

Our “Patterns for API Design” book was presented by Daniel Lübke. He motivated why patterns are well suited to share API design knowledge, explained the focus of the book on message content and presented Context Representation as an example. One take-away message was:

Patterns are great, but “the more, the better” is not an adequate approach to using them.

The language is organized into categories (Foundation Patterns not shown):

The landing page for our book is here. Free content that is available online includes extended pattern summaries, tutorials, pointers to articles, presentations and podcasts. The InformIT website also has two Web extras, “How to Shape Responses to API Calls” and “What is the Right Service Granularity in APIs?”.

“Visualizing API Patterns”

Cesare Pautasso, another co-author of our book, provided a behind-the-scenes view on pattern mining in Web APIs (HTTP APIs on different levels of REST maturity, that is). Via many examples, he demonstrated that:

The URI structure of HTTP resource APIs tells you a lot about its semantics.

Cesare visualized the URI structure of instances of the Processing Resource and Information Holder Resource patterns. He reported that a lot of APIs use the HTTP verbs in ways that go against their original and intended semantics — for reasons unknown from his analysis that uses OpenAPI specification parts. For instance, GET requests send commands, POST requests retrieve data and so on. On the pattern level, we call these types of operations, which differ in their read-write characteristics, operation responsibilities.

The visualizations in Cesare’s talk result from Ph.D. research in his group. oas2tree makes them available as a Visual Studio Code extension so that you can visualize your own APIs. His slides from the event are here.

“Messaging 101: The Basics of Message-Driven Systems”

Alex Lawrence, the author of “Implementing DDD, CQRS and Event Sourcing”, reminded us of the essence and the advantages of asynchronous messaging (in the cloud and on-premises). Message brokers are a key middleware component in this integration style.⁴ Messaging reduces coupling — in the time dimension and in the platform dimension. It also allows communication participants to evolve independently and scale autonomously; all they need to know about each other is the names of the channels they use to send and receive messages (reference autonomy).⁵

We agree with Alex’s positioning of events vs. messages: not every message contains an event, but each event is reported as a message; this is an is-a relationship in the application integration domain. His collection of four types of messages — command, query, event, response — pointed out a very welcome connection from event storming and DDD to messaging. He introduced a color coding frequently used in event storming workshops (blue, green, orange) for these message types. You might ask whether a query response different from a command response? It depends… on the command and query semantics; sometimes, such messages simply contain an atomic “got it” acknowledgment and sometimes deeply nested Parameter Trees are returned.

After the talk, Alex and Olaf had a fruitful conversation on reply-to metadata (e.g., in JMS), on guaranteed delivery (mandatory or optional? quality-of-service variants?), on terminology differences between Apache Kafka, messaging systems such as RabbitMQ and various cloud offerings (topics vs. channels vs. queues; events vs. messages). “Enterprise Integration Patterns” (EIP) established a common language for messaging back in 2003. Although terminology has changed since then, its patterns are still very valid.⁶

Let’s map the message types from the talk to EIP and our book:

We look forward to Alex’s book in the Signature Series, currently under subject matter expert review.

“Domain-Driven Transformation – How to Bring (Back) Sustainable Architecture to Legacy Software and Monoliths”

Carola Lilienthal author of several books, gave another very inspiring talk. It was reassuring to hear that DDD can be used to modernize systems; a book on this topic is under way. Carola used the same subdomain-bounded context overlay as Vaughn’s “Implementing Domain-Driven Design” book.

A Modularity Maturity Index (MMI) uses 22 weighted factors (45% modularity, 30% hierarchy, 25% patterns) to assess reengineering needs and opportunities. The MMI gives management and teams a guideline for deciding which software systems need to be refactored, which ones should be replaced, and which ones they do not need to worry about.

At the end of her talk, Carola presented promising work in progress — three types of domain characteristics and examples of them: pipeline, blackboard, dialog. This work might yield something that was missing so far in our body of software engineering knowledge. Let’s try to show the gap in a table:

Does this characterization of domain types by users and their usage profiles⁷ and by quality characteristics⁸ lead to domain patterns (there probably are more than these three)? And can these domain patterns ground and drive architectural decisions?

“Exploring Bi-temporality in Domain Modeling and Architecture”

Tomasz Jaskula topic let me react as this: “I have been there, but didn’t appreciated the complexity and subtleties”. He motivated why this aspect of domain modeling is so important in several use cases and then went deep, covering not just bi-temporality, but tri-temporality. Up to three related dates/times can be distinguished per domain event, for instance validity date, transaction date and information date. He provided many concrete examples, including order management:

I took away a call to action:

Take your time to model time-related aspects carefully and accurately!

Tomasz ended with a nice collection of bitemporal event sourcing patterns (retroactive backdating, forward-dating and back-patching/forward patching, cancellation, scheduling) and reactive paradoxes (stream/history inconsistency, casuality violations, casual loop) plus fixes for them. Food for a new book?

“Refining Your API: The Last Mile of API Design”

James Higginbotham, author of “Principles of Web API Design”, introduced his Align-Define-Design-Refine (ADDR) process and then covered the Refine phase in depth.

ADDR promotes jobs-to-be-done and job story orientation; the talk featured examples of such job stories. Supporting an API-first approach to design⁹ is a theme that James’ book shares with ours and others in the API design space (see this post). He reminded us that API usages are conversations and showed several API sequence diagrams.¹⁰ James also went into APIs in microservices architectures and commented that coordination always incurs cost.

The slides from this presentation are available at SlideShare:

You might be wondering why there are two books on API design in the series. They are designed to be complementary: process and principles (James) vs. patterns (Olaf and his team). The introduction to Part 2 and Appendix A of our book bring the concepts together, and our chapter naming scheme in Part 2 is inspired by ADDR.¹¹

“Perfect 10”

Vaughn Vernon closed the intense day by giving a keynote-type presentation. Much food for thought! For instance, he reminded us of Conway’s Law and recommended reading the entire article from 1968 until the end; the reverse Conway maneuver is covered in it.

Vaughn then provided two very interesting book tips: David Bohm’s “On Dialogue” and Peter Gärdenfors’s “Geometry of Meaning”. Communication types include, well, communication (make something common, e.g., information), discussion and dialog. Dialog and learning happen best in context. A key message was:

The loudest and the longest talkers harm both hierarchical and one-team structures (in social architectures).

In conceptual spaces (from “Geometry of Meaning”), agents send force vectors (which have a direction and a magnitude) to patients; events capture the entire experience of an agent exerting a force on a patient causing a result. Non-agents may cause actions/activities too (time, gravity). These concepts correspond to bounded contexts (or subdomains), actors, commands (actions/activities), and entities, as used in DDD and API design. Finding such connections and inspiration is what events like this are all about!¹²

Domo is a domain-driven modeling tool developed by Kalele. It can be used for DDD experimentation. Sign-in is required, but usage is free after that.

As a bonus, Vaughn mentioned our DDD DSL and tools Context Mapper as an open source project with a product mindset. 😃

Wrap Up and Acknowledgments

The event had 409 unique viewers, with a peak of 219 simultaneous views. It had viewers from 44 different countries. Recordings of all presentations are available on Youtube.

Thanks to Workplace Solutions, Stefan Hofer in particular, for having/hosting us! Thanks to Vaughn Vernon for bringing us together, it is an honor to be part of this group of authors!

– Mirko and Olaf, 40% of the co-authors of “Patterns for API Design: Simplifying Integration with Loosely Coupled Message Exchanges”.

This post is also available on Medium: Part 1, Part 2

You can find the all books in the series at InformIT.

Notes.