Notes from “The Architecture and Modeling Learning Event”, Part 2
Vaughn Vernon Signature Series Live in Action (May 12, 2023)
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 story covers the afternoon; the first six talks are summarized in Part 1 of our notes. Note that these are personal impressions; we do not aim to be complete.
“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 on 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 Stocker and Olaf Zimmermann, 40% of the co-authors of “Patterns for API Design: Simplifying Integration with Loosely Coupled Message Exchanges”.
You can find the all books in the series at InformIT.
Notes
- Messaging is one of several integration styles; see an IEEE Software Insights by Cesare Pautasso and Olaf Zimmermann for an introduction and comparison of six such styles.
- Time, platform and reference are four dimensions of loose coupling; Vlad’s talk introduced even more types. Gregor Hohpe’s posts on this topic also come to mind, for instance, “I made everything loosely coupled. Will my cloud bill go up?”.
- The paper “Reliable Event Routing in the Cloud and on the Edge: An Internet-of-Things Solution in the AgeTech Domain”, joint work with students at OST, covers delivery guarantees (in the context of IoT and MQTT).
- Domain Storytelling!
- Continuous Architecture in Practice!
- First after requirements elicitation and domain modeling, but before coding or opening existing backend systems or data.
- UML is back? It actually never went away.
- And we have an API design-refine review checklist too. 😉
- For more information about conceptual spaces, refer to this paper and this presentation.
Originally published at https://ozimmer.ch on May 26, 2023.
