Consider the following situation.
Three apps A,B and C must cooperate together: A is an external, third party app while B and C are in-house apps (so we have control over B and C, not over A). B replies to requests made by A, using both logics contained in C and B itself. Think about B as a layer between A and C.
There are some underlying common concepts that A,B and C understand and use.
Suppose the key task here is to decouple everything, so that if tomorrow we want to use A1 instead of A, all the interactions between B and C stay fixed (and, respectively if we want to use C1 instead of C, all the interactions between B and A stay fixed).
The question is about the datamodel design for B and C. Two solutions come to my mind:
- Shared datamodel: we introduce a datamodel D in a different project. D contains the "in house" version of the common concepts and is used by B and C: an A-version of the concept is mapped to a D-version and can be used and understood by both B and C. If tomorrow we want to use A1 instead of A, we simply re-write the adapter. If instead we want to get rid of C, we write C1 using the common datamodel D.
- Replicated datamodel: both B and C have its own version of the datamodel. We now have two adapters: one between A and B and one between B and C. If tomorrow we want to change either A or C then we rewrite the respective adapter.
Is there any best practice for dealing with this situation? Is there any alternative to 1. and 2.? Is there any intrinsic problem with either 1. and 2.?
Aucun commentaire:
Enregistrer un commentaire