{"id":1737,"date":"2026-08-18T16:24:21","date_gmt":"2026-08-18T16:24:21","guid":{"rendered":"https:\/\/freitas.eti.br\/?p=1737"},"modified":"2026-08-19T00:34:37","modified_gmt":"2026-08-19T00:34:37","slug":"chapter-3-transaction-domain","status":"publish","type":"post","link":"https:\/\/freitas.eti.br\/pt-br\/chapter-3-transaction-domain\/","title":{"rendered":"Chapter 3 \u2014 Transaction Domain"},"content":{"rendered":"
\n
\n

Chapter 3<\/h4><\/div>\n\n\n\n

Transaction Domain<\/h2><\/div>\n<\/div>\n\n\n\n
\n

The Orchestrator of the Payment Journey<\/h3>\n\n\n\n

Every payment begins with uncertainty.<\/p>\n\n\n\n

At the moment a payment request enters the platform, no final decision exists. The transaction has not yet been trusted, authorized, settled or analyzed. The platform only knows that a customer is attempting to pay a merchant, and that this attempt needs to be transformed into a controlled business process.<\/p>\n\n\n\n

This is the role of the Transaction Domain.<\/p>\n\n\n\n

It is not responsible for deciding whether a transaction is fraudulent. It is not responsible for communicating with issuers or card networks. It is not responsible for moving money to the merchant. Those responsibilities belong to other domains.<\/p>\n\n\n\n

The Transaction Domain exists to coordinate the journey. It gives the transaction an identity, records its initial state and ensures that each step of the payment lifecycle can be followed in a consistent and traceable way.<\/p>\n\n\n\n

In a modern payment platform, orchestration is not about centralizing every decision. It is about creating a reliable structure through which specialized domains can collaborate.<\/p>\n<\/div><\/div>\n\n\n\n

<\/div><\/div>\n\n\n\n
\n

Why Transaction Orchestration Matters<\/h3>\n\n\n\n
\n
\n
\n

Payment platforms rarely fail because a single operation is difficult to execute. They fail because many operations need to happen together, under time pressure, across systems that may not always behave predictably.<\/p>\n\n\n\n

A fraud engine may respond quickly or slowly. An external authorization provider may approve, decline or timeout. A settlement process may depend on rules that are only evaluated later. Analytical systems may need to consume events after the operational flow is completed.<\/p>\n\n\n\n

Without orchestration, these interactions become difficult to understand and even harder to support.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

The Transaction Domain creates the operational backbone of the payment journey. It allows the platform to answer basic but critical questions:<\/p>\n\n\n\n

    \n
  • When did the transaction start?<\/li>\n\n\n\n
  • Which merchant initiated it?<\/li>\n\n\n\n
  • What is the current state?<\/li>\n\n\n\n
  • Which domains participated in the journey?<\/li>\n\n\n\n
  • What decision was produced?<\/li>\n\n\n\n
  • Where did the process fail, if something went wrong?<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n
    \n

    These questions may appear simple, but they are essential in payment systems. When money, risk and customer experience are involved, traceability is not a technical luxury. It is a business requirement.<\/p>\n<\/div>\n<\/div><\/div>\n\n\n\n

    <\/div><\/div>\n\n\n\n
    \n

    Identity Before Decision<\/h3>\n\n\n\n

    This identity allows every subsequent domain to participate in the same business process without owning the entire process.<\/p>\n\n\n\n

    \n
    \n
    \n

    One of the first responsibilities of the Transaction Domain is establishing identity.<\/p>\n\n\n\n

    Before the platform can evaluate fraud, request authorization or prepare settlement, the transaction must become something the system can consistently reference. It needs an identifier, a state and a place in the operational history of the platform.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n

    The Fraud Domain can evaluate risk for a known transaction. The Authorization Domain can request approval for a known transaction. The Settlement Domain can prepare financial outcomes for a known transaction. The Analytics Domain can later interpret what happened across the full lifecycle.<\/p>\n\n\n\n

    Without a stable transaction identity, the platform would be forced to reconstruct the journey from disconnected technical events. That approach may work in small systems, but it quickly becomes fragile as volume, integrations and failure scenarios increase.<\/p>\n\n\n\n

    It should be a business object with a history.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

    \n

    A transaction should not be just a request moving through services.<\/p>\n<\/div>\n<\/div><\/div>\n\n\n\n

    <\/div><\/div>\n\n\n\n
    \n
    \"\"<\/figure><\/div>\n<\/div>\n\n\n\n
    <\/div><\/div>\n\n\n\n
    \n

    Coordination Without Ownership Creep<\/h3>\n\n\n\n
    \n
    \n
    \n

    A common mistake in distributed architectures is allowing the orchestrating component to become responsible for too much.<\/p>\n\n\n\n

    Because the Transaction Domain sees the full journey, it may be tempting to place business rules inside it. Fraud shortcuts, authorization decisions, settlement rules and analytical concerns can slowly accumulate in the orchestration layer.<\/p>\n\n\n\n

    This creates a dangerous form of coupling.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n

    The Transaction Domain should understand the journey, but it should not own every decision inside the journey. Its responsibility is to coordinate specialized domains, not to replace them.<\/p>\n\n\n\n

    In PaymentHub, this distinction is important. The Transaction Domain knows that fraud evaluation must happen, but it does not own the fraud strategy. It knows that authorization must be requested, but it does not own the external payment network integration. It knows that settlement will eventually matter, but it does not own financial reconciliation.<\/p>\n\n\n\n

    This separation keeps the architecture understandable.<\/p>\n\n\n\n

    It also allows each domain to evolve independently. Fraud rules can change without rewriting the transaction orchestration model. Authorization providers can evolve without changing the meaning of a transaction. Settlement processes can become more sophisticated without forcing the Transaction Domain to become a financial engine.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

    \n

    Good orchestration creates flow without absorbing every responsibility.<\/p>\n<\/div>\n<\/div><\/div>\n\n\n\n

    <\/div><\/div>\n\n\n\n
    \n

    State and Traceability<\/h3>\n\n\n\n

    A transaction may be created, pending fraud analysis, authorized, declined, failed, reversed, captured, settled or partially processed depending on the complexity of the platform. Even when the initial implementation starts with a simpler state model, the architecture should leave room for that model to evolve.<\/p>\n\n\n\n

    \n
    \n
    \n
    \n
    Created<\/h6><\/div>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    Pending Fraud<\/h6><\/div>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    Authorized<\/h6><\/div>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    Captured<\/h6><\/div>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    Settled<\/h6><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    \n
    \n
    Declined<\/h6><\/div>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    Failed<\/h6><\/div>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    Reversed<\/h6><\/div>\n<\/div>\n<\/div>\n\n\n\n
    \n
    \n
    Partially Processed<\/h6><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n
    \n

    The state of a transaction is one of the most important pieces of information in a payment platform.<\/p>\n\n\n\n

    State is not only useful for software execution. It is also useful for people.<\/p>\n\n\n\n

    Support teams need to understand what happened when a customer reports an issue. Operations teams need to identify failures and exceptions. Product teams need to understand where conversion is being lost. Engineering teams need to diagnose behavior across services.<\/p>\n\n\n\n

    A well-designed Transaction Domain turns the payment journey into something observable.<\/p>\n\n\n\n

    This does not mean storing every technical detail inside the domain itself. It means preserving enough business context to make the transaction understandable over time.<\/p>\n\n\n\n

    \n

    In payment architecture, the ability to explain what happened is often as important as the ability to process what is happening.<\/p>\n<\/blockquote>\n<\/div>\n<\/div><\/div>\n\n\n\n

    <\/div><\/div>\n\n\n\n
    \n

    From Synchronous Flow to Event-Driven Evolution<\/h3>\n\n\n\n

    PaymentHub begins with a synchronous communication model because it makes the initial journey easier to understand, implement and validate.<\/p>\n\n\n\n

    \n
    \n
    \n

    This is a deliberate choice.<\/p>\n\n\n\n

    Starting with synchronous APIs allows the platform to focus first on business boundaries and domain responsibilities. It keeps the early architecture easier to reason about and reduces operational complexity while the model is still evolving.<\/p>\n<\/div>\n<\/div>\n\n\n\n

    \n
    \n

    However, the Transaction Domain is also a natural candidate for future event-driven evolution.<\/p>\n\n\n\n

    As the platform matures, important moments in the transaction lifecycle can become domain events. A transaction can be created. Fraud can be evaluated. Authorization can be completed. Settlement can be prepared. Analytics pipelines can consume these events without forcing every domain to participate in the same synchronous flow.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

    \n

    This evolution changes the architecture from direct coordination to a more scalable collaboration model.<\/p>\n\n\n\n

    The important point is that event-driven architecture should not be introduced only because it is fashionable. It should appear when the platform has clear events, clear consumers and clear reasons to decouple parts of the journey.<\/p>\n\n\n\n

    The Transaction Domain helps create that foundation by making the lifecycle explicit.<\/p>\n<\/div>\n<\/div><\/div>\n\n\n\n

    <\/div><\/div>\n\n\n\n
    \n

    Nota do Arquiteto<\/h3>\n\n\n\n
    \n

    A useful way to think about the Transaction Domain is to compare it with a flight itinerary.<\/p>\n\n\n\n

    The itinerary does not fly the aircraft, operate the airport, inspect security or manage baggage. Each of those responsibilities belongs to a specialized capability.<\/p>\n\n\n\n

    But the itinerary gives structure to the journey. It connects departure, connection, arrival, timing and status into a single experience that can be understood and tracked.<\/p>\n\n\n\n

    The Transaction Domain plays a similar role in PaymentHub.<\/p>\n\n\n\n

    It does not perform every business decision, but it gives the payment journey a structure that the platform can follow, observe and evolve.<\/p>\n<\/blockquote>\n<\/div><\/div>\n\n\n\n

    <\/div><\/div>\n\n\n\n
    \n

    Looking Ahead<\/h3>\n\n\n\n
    \n

    The Transaction Domain is where operational clarity begins.<\/p>\n\n\n\n

    It transforms a payment request into a traceable business process and creates the foundation for every subsequent decision in the platform. Without it, Fraud, Authorization, Settlement and Analytics would still exist, but their interactions would be harder to coordinate and harder to understand.<\/p>\n\n\n\n

    In the next chapter, the journey moves from coordination to trust.<\/p>\n\n\n\n

    Before the platform asks whether a transaction can be approved, it must ask whether the transaction should be trusted.<\/p>\n\n\n\n

    That question belongs to the Fraud Domain.<\/p>\n<\/div>\n<\/div><\/div>\n<\/div><\/div>","protected":false},"excerpt":{"rendered":"

    Chapter 3 Transaction Domain The Orchestrator of the Payment Journey Every payment begins with uncertainty. At the moment a payment request enters the platform, no final decision exists. The transaction has not yet been trusted, authorized, settled or analyzed. The platform only knows that a customer is attempting to pay a merchant, and that this […]<\/p>\n","protected":false},"author":1,"featured_media":1670,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_uag_custom_page_level_css":"","_monsterinsights_skip_tracking":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"disabled","ast-breadcrumbs-content":"","ast-featured-img":"disabled","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[9],"tags":[15],"class_list":["post-1737","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-paymenthub-architecture-series","tag-paymenthub-softwarearchitecture-ddd-payments-aws-cloudarchitecture-platformengineering"],"uagb_featured_image_src":{"full":["https:\/\/freitas.eti.br\/wp-content\/uploads\/2026\/07\/chapter3-transaction-domain.png",1536,1024,false],"thumbnail":["https:\/\/freitas.eti.br\/wp-content\/uploads\/2026\/07\/chapter3-transaction-domain-150x150.png",150,150,true],"medium":["https:\/\/freitas.eti.br\/wp-content\/uploads\/2026\/07\/chapter3-transaction-domain-300x200.png",300,200,true],"medium_large":["https:\/\/freitas.eti.br\/wp-content\/uploads\/2026\/07\/chapter3-transaction-domain-768x512.png",768,512,true],"large":["https:\/\/freitas.eti.br\/wp-content\/uploads\/2026\/07\/chapter3-transaction-domain-1024x683.png",1024,683,true],"1536x1536":["https:\/\/freitas.eti.br\/wp-content\/uploads\/2026\/07\/chapter3-transaction-domain.png",1536,1024,false],"2048x2048":["https:\/\/freitas.eti.br\/wp-content\/uploads\/2026\/07\/chapter3-transaction-domain.png",1536,1024,false],"trp-custom-language-flag":["https:\/\/freitas.eti.br\/wp-content\/uploads\/2026\/07\/chapter3-transaction-domain.png",18,12,false]},"uagb_author_info":{"display_name":"Freitas","author_link":"https:\/\/freitas.eti.br\/pt-br\/author\/robertofreitas-eti-br\/"},"uagb_comment_info":0,"uagb_excerpt":"Chapter 3 Transaction Domain The Orchestrator of the Payment Journey Every payment begins with uncertainty. At the moment a payment request enters the platform, no final decision exists. The transaction has not yet been trusted, authorized, settled or analyzed. The platform only knows that a customer is attempting to pay a merchant, and that this…","_links":{"self":[{"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/posts\/1737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/comments?post=1737"}],"version-history":[{"count":8,"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/posts\/1737\/revisions"}],"predecessor-version":[{"id":2264,"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/posts\/1737\/revisions\/2264"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/media\/1670"}],"wp:attachment":[{"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/media?parent=1737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/categories?post=1737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/freitas.eti.br\/pt-br\/wp-json\/wp\/v2\/tags?post=1737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}