> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/event-driven-architecture/event-governance-the-foundation-of-successful-event-driven-architecture/day-9-14-leveraging-the-topic-name-or-event-flow-guideline-based-on-the-naming-standard.md). # Day 9/14 Leveraging the Topic Name or Event Flow Guideline based on the Naming Standard Day 9 of 14: Learn how to leverage structured topic names and wildcards in an ePayment architecture to achieve dynamic routing without hardcoded backend logic. In the realm of system events, consistency in representing the event message topic is key, despite the varied interpretations across systems. The core topic denoting the event's message should remain unwavering. When naming topics, the data component values of the event (comprising mandatory and optional parts) must align solely with the original event's purpose.\ \ Consider the scenario of ePayment services. Requests for ePayment are initiated through diverse channels like web, mobile, ATM, and bank, each directing the requests to specific payment services via distinct event pathways. In a schematic representation, the initial three event pathways cater to EFT, PPS, and FPS, with the final one focusing on bank fund transfers.\ \ In each event pathway, the **mandatory elements** (highlighted in red and blue) are encapsulated in the message header and persist across all subsequent messages within the pathway. These mandatory components remain constant throughout the **event pathway's lifecycle**. The output topic for each component comprises the input messages' mandatory segment, the component function, and the process status. Subscribing to all relevant events within the same pathway is facilitated by employing a wildcard approach. Below illustrates an instance of the EFT transaction pathway.\ \ Please note that the definitions of "**Mandatory Part**" and "**Optional part**" differ between the Topic Naming standard \[] and event flow control. The Topic Naming Standard emphasizes categorizing and naming various distinct events, whereas event flow control is concerned with managing and tracking the progression of the same event through its different stages. In each event pathway, the mandatory elements (highlighted in red and blue) are encapsulated in the message header and persist across all subsequent messages within the pathway. These mandatory components remain constant throughout the event pathway's lifecycle. The output topic for each component comprises the input messages' mandatory segment, the component function, and the process status. Subscribing to all relevant events within the same pathway is facilitated by employing a wildcard approach. Below illustrates an instance of the EFT transaction pathway. Flexibility is key when it comes to managing components within the backend account service. Here are some key benefits to consider: * **Easily Customize Components**: You have the freedom to add or remove components without the need for coding changes in the topic routing logic. This means adjusting subscriptions for individual components, such as handling different payment event flows to update customer balances, is a seamless process. The status updates are efficiently returned to the relevant topics without hassle. * **Streamlined Event Subscriptions**: You can effortlessly subscribe to all relevant events from specific event flows using wildcards. This simplifies the process of staying updated on various activities within the system. * **Efficient Event Collection**: By defining specific conditions, you can effectively gather all related events. For instance, monitoring all activities related to a specific account (e.g., product selling, account operations, statement inquiries, ePayments, etc.) becomes a straightforward task. * **Application Logic Flexibility**: The application does not come with predefined or hardcoded logic for routing in handling multiple event flows. This means requests like updating customer profiles or system configurations can be easily accommodated within the backend account service. Each component only needs to process messages and post results back to the corresponding topics, ensuring smooth operations without the need for complex routing logic. By maintaining a consistent mandatory part in the topic names across the entire event flow, the backend account service ensures seamless processing without the need for constant changes. This standardized approach enhances efficiency and simplifies the management of diverse event flows.
## 🚀 Let's Connect Beyond GitBook! If you found this article helpful, you can find more of my technical insights, daily discussions, and deep dives across these platforms: * **Read more of my work:** Check out my articles on [dev.to](https://dev.to/stephen_tsoi_5b2c4055f3a9) and [Hashnode](https://stephentsoi.hashnode.dev/). * **Join the daily conversation:** Connect with me directly on [LinkedIn](https://www.linkedin.com/in/stephen-tsoi-16309730/). *** #### 📬 Stay Ahead of the Curve Enjoyed this piece? I break down complex technical topics into bite-sized, actionable insights every week. 👉 **Subscribe to my** [**LinkedIn Newsletter**](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7487299517642612736) to never miss an update and get the latest articles delivered straight to your feed! --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/event-driven-architecture/event-governance-the-foundation-of-successful-event-driven-architecture/day-9-14-leveraging-the-topic-name-or-event-flow-guideline-based-on-the-naming-standard.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.