Message Mapper Design Considerations

Question

Long question context, skip to tl;dr for the meat of it.

I am designing an integration between two web applications, and have come to the conclusion that a message pattern would be an appropriate solution to the problem. The gist of the requirements is that data in System A should be synced to System B, through an interface in System A. All requests are http requests. The data in System A is an object database, the data in System B is a relational database. System B accepts and returns JSON for every call, while System A uses domain-specific formats. In addition, all business logic has to be in System A. System B is a black box, and only allows access to the data layer.

I experimented with a Transfer Object Assembler Pattern, but found that this was not quite right for the integration. Each combination of object and operation on System B ultimately has to be done with a separate request. If I need to update a user and an organization, these have to be in separate calls to separate resources. Using the DTO pattern here would require a separate data transfer object for each call, which kind of defeats the purpose (as far as I understand).

Long story short, the message pattern seems to be the way to go. Bonus points since it's a short jump to using an actual message bus for integrations in the future. So now, the idea is to create a message for each operation type. CreateMessage, UpdateMessage, etc. Each message would have an instance of a parameter class that specifies the type of object, and the JSON body of the message. The only missing piece is translating the System A domain data into JSON, and JSON into System A data.

tl;dr

I want to write this correctly so that the next guy doesn't have to maintain really poorly written/designed code.

I'm thinking of using the Message Mapper pattern to transform an object from System A to a Create/Update/Delete/Read message with a JSON center, so that it can be executed in System B. System A is OO, but doesn't support generics. Would it be more practical to write a collection of classes that are 1:1 with the domain as we need them, or a monolithic class that does all the mapping? I really don't like the idea of any very large class, but since generics aren't an option it's difficult to tell which is more appropriate.

Can you provide a brief example of your proposed Message Mapper pattern implementation? — Robert Harvey, Jan 25 '16 at 21:39
I'm thinking of using a mapper to transform objects into JSON, and then building a command message object using that JSON as parameters, and finally passing the resulting object to the integration framework. The problem is in the mapping step, where (as far as i can tell) i'd need to put mapping methods for each domain object into one big class, or several small classes that do almost identical things. — Aj_76, Jan 26 '16 at 16:48

YSharp · Answer 1 · 2016-03-11T07:34:30.427

(Quoting)

"The only missing piece is translating the System A domain data into JSON, and JSON into System A data."

I don't mean to suggest you to use that other puppy you are likely familiar with, also (read on), but if you can (1) reason for a few minutes on what your "System A domain data" would look like if serialized, in, say, the XML puppy, and (2) could devise a simple, general (i.e., generic), easy-to-implement two-way mapping about it (your System A domain data <-- --> XML) then you may also want to check out this very simple, novel (it seems?), and pretty natural embedding of XML within JSON, child nodes- and document order-friendly, that I've eventually noticed and been toying around lately:

https://jsfiddle.net/YSharpLanguage/dzq4fe39/1

(which I believe is nicely round-trippable, also)

E.g., as a contrived example,

From (pseudo-code domain):

class CustomerAccount
{
  string AccountNumber { get set }

  // etc
}

class Customer {
  int Id { get set }

  string FirstName { get set }

  string LastName { get set }

  DateTime CustomerSince { get set }

  Customer Referral { get set }

  CustomerAccountList Accounts { get set }
}

To (canonical XML):

<Customer>
  <Id>123</Id>
  <FirstName>John</FirstName>
  <MiddleName/>
  <LastName>Smith</LastName>
  <CustomerSince>...</CustomerSince>
  <Referral idref="456" relation="manyToOne"/>
  <Accounts relation="oneToMany">
    <CustomerAccount>
      <AccountNumber>...</AccountNumber>
      <!-- etc -->
    <CustomerAccount>
    <CustomerAccount>
      <AccountNumber>...</AccountNumber>
      <!-- etc -->
    <CustomerAccount>
  </Accounts>
  <!-- etc -->  
</Customer>

Or also (equivalent JSON of interest):

[ { "": "Customer" },
  [ { "": "Id" }, 123 ],
  [ { "": "FirstName" }, "John" ],
  [ { "": "MiddleName" } ],
  [ { "": "LastName" }, "Smith" ],
  [ { "": "CustomerSince" }, "..." ],
  [ { "": "Referral", "idref": 456, "relation": "manyToOne" } ],
  [ { "": "Accounts", "relation": "oneToMany" },
    [ { "": "CustomerAccount" },
      [ { "": "AccountNumber" }, "..." ]
    ],
    [ { "": "CustomerAccount" },
      [ { "": "AccountNumber" }, "..." ]
    ]
  ]
]

'HTH,

Message Mapper Design Considerations

1 Answers1