In a Galera cluster, a node can log 2 kinds of transactions.

1. Galera transactions : Ones which are replicated to other nodes within the cluster post-SST.
2. Local transactions : Local transactions can be transactions involving non-innodb (except myisam when --wsrep-replicate-myisam is enabled) DMLs which are not relayed to other nodes.

Now, in a scenario where galera-transactions from one cluster are being
asynchronously replicated to an another cluster using the traditional
MariaDB replication, having following 2 additional features would come in
handy during setup and maintenance of such replication topologies.

1. Separate domain_id for Galera-transaction :

   An external 'listener' of an n-node galera cluster can essentially
   see n (=local transactions) + 1 (=galera transactions) logical streams
   of transactions. So, having all galera transactions logged using a separate
   domain_id would make it easier to identify, filter (see #2) and replicate
   those transactions to an external replication slave or a different cluster
   altogether.

   This task introduces a new GTID domain ID (wsrep_gtid_domain_id) to be
   used to tag all galera transactions. The local transactions, however,
   will be tagged by gtid_domain_id as usual.

   Now, since the Galera transactions can originate on any of the nodes,
   it is important that all the cluster nodes have same GTID domain ID
   (wsrep_gtid_domain_id). So, in order to enforce this, SST (Snapshot
   State Transfer) scripts have been modified to automatically transfer
   the value of donor's wsrep_gtid_domain_id to the joiner node during
   SST process. This will make sure that all the nodes in the cluster
   have same wsrep_gtid_domain_id and thus all the galera transactions
   will essentially have same domain ID.

   A new server system variable wsrep_gtid_mode has been introduced to
   control this new behavior an this remain backward compatible. When OFF
   (default), wsrep_gtid_domain_id is ignored and all the transactions will
   be tagged based on gtid_domain_id. On the other hand, when wsrep_gtid_mode
   is ON, wsrep_gtid_domain_id takes effect and will be used to mark all
   Galera transactions.

   New Server System Variables:

   1. wsrep_gtid_domain_id:
      • Description: When wsrep_gtid_mode is set, this value is used as gtid_domain_id for galera transactions and also copied to the joiner nodes during state transfer. It is ignored, otherwise.
      • Dynamic: Yes
      • Data Type: Numeric (32-bit unsigned integer)
      • Default : 0
   2. wsrep_gtid_mode:
      • Description: Automatically update the (joiner) node's wsrep_gtid_domain_id value with that of donor's (received during state transfer) and use it in place of gtid_domain_id for all galera transactions. When OFF (default), wsrep_gtid_domain_id is simply ignored (backward compatibility).
      • Scope: Global
      • Dynamic: Yes
      • Data Type: Boolean
      • Default value : False

   Changes in SST scripts:

   • wsrep_sst_rsync :
     The script has been modified to also transfer donor's wsrep_gtid_domain_id alongwith the state ID.

   • wsrep_sst_xtrabackup (-v2) :
     Similar to the rsync SST script, the xtrabackup scripts have been modified to also transfer donor's
     wsrep_gtid_domain_id alongwith the state ID.

   • wsrep_sst_mysqldump :
     The script has been modified to set joiner's wsrep_gtid_domain_id with that of donor's only when Joiner's wsrep_gtid_mode=ON.

2. Domain_id based replication filters (MDEV-6593) :

   Enable a replication slave to filter and apply transactions based on
   transaction's domain_id. As described above, this would enable the
   asynchronous replication of galera transaction outside the galera
   cluster.

A use case described here:
http://linsenraum.de/erkules_int/2014/07/galera-cluster-using-gtid-mysql-vs-mariadb.html