{
  "id": 15510141,
  "title": "Part 1: Where Should Communications Live?",
  "url": "https://urgent.news/2026/10/18/part-1-where-should-communications-live",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-18T23:00:00.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/jeremy_tly/part-1-where-should-communications-live-505l"
  },
  "original_language": "en",
  "account": "In the world of software development, applications constantly communicate with one another. These communications can take the form of notifications such as order confirmations, password resets, welcome emails, shipping updates, and security alerts. At first glance, these communications may appear to be a routine aspect of an application's functionality. However, as an application grows, it is crucial to recognize that they require a separate architectural concern.\n\nFor small applications, integrating communications within the same process can be a viable approach. However, as the application scales and becomes more complex, a dedicated communications architecture becomes essential. This is where Microsoft's .NET eShop reference application comes into play.\n\neShop demonstrates the importance of having a separate communications service, particularly when dealing with order confirmations. While it may be tempting to simply inject an IEmailClient into the Ordering service and call it a day, this approach would ultimately undermine the boundaries that eShop was designed around. The key to addressing this issue lies in determining where the communications service's boundary should reside and why.\n\nWhen considering where the order communication belongs, it is essential to recognize that an order confirmation represents a view of the business that spans several boundaries. Building the message may require data from multiple domains such as Ordering, Identity, Payment, Shipping, and more. Thus, the ownership question becomes clearer when acknowledging that the communication has its own model and lifecycle.\n\nAs the complexity of communication requirements grows, it is easy to fall into the trap of allowing Ordering to become responsible for orchestrating data and behavior related to customer communications. This can lead to a situation where Ordering knows more than it should, conflicting with its primary purpose of managing orders. Instead, each domain should be responsible for knowing what is relevant to its own responsibilities.\n\nIn conclusion, as applications evolve and require more sophisticated communications, it is crucial to maintain clear boundaries and domain responsibilities. By separating the communication service from the originating domain, developers can ensure that each domain remains focused on its core responsibilities, resulting in a more maintainable and scalable application architecture.",
  "summary": "Almost every application sends communications. Most of us call them notifications: order confirmations, password resets, welcome emails, shipping updates, security alerts. They're so ordinary that, while an application is new, nobody treats them as a separate architectural concern. They usually start like this: await emailClient . SendAsync (...); Maybe the application uses an SMTP server. Maybe…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}