3

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.

2
  • 1
    Can you provide a brief example of your proposed Message Mapper pattern implementation? Jan 25, 2016 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, 2016 at 16:48

1 Answer 1

-2

(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,

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.