technology:domainmodel:boundedcontext:modelintegrity:customersupplier
Differences
This shows you the differences between two versions of the page.
|
technology:domainmodel:boundedcontext:modelintegrity:customersupplier [2013/01/31 18:12] rtavassoli [Integration via Database Views] |
technology:domainmodel:boundedcontext:modelintegrity:customersupplier [2013/02/01 16:21] (current) rtavassoli |
||
|---|---|---|---|
| Line 34: | Line 34: | ||
| ==== To use Database Integration or not to use ==== | ==== To use Database Integration or not to use ==== | ||
| As always, it depends. If you can always rely on the possibility of integrating via the database, go for it. Actually, if it is a possibility in the current situation, go for it. If things change, move to a different polling solution or maybe even to a push solution. But if there is no need for a more complicated and less consistent solution, you should not make that move right away. | As always, it depends. If you can always rely on the possibility of integrating via the database, go for it. Actually, if it is a possibility in the current situation, go for it. If things change, move to a different polling solution or maybe even to a push solution. But if there is no need for a more complicated and less consistent solution, you should not make that move right away. | ||
| + | \\ \\ | ||
| + | The implementation of the read model will have a dependency on the available integration technologies with supplier contexts- that's a real drawback. A simple salvation is to wrap the customers read model with an abstract view representation. That view can then be built either by direct database integration, by pulling date from the supplier or by having data pushed from the supplier: | ||
| + | \\ | ||
| + | {{ :technology:domainmodel:boundedcontext:modelintegrity:customersupplierintegrationabstraction.png?nolink |}} | ||
| + | \\ | ||
| + | If you now choose to directly integrate through the database, changing that decision later will only result in you having to change the way the abstract view is //fed//. If you move from direct database integration to a push or pull solution, you will also move to an eventually consistent representation of the suppliers part of the data of the read model. That may or may not be something to consider. If it is, you can //add// information to the read model. You could | ||
| + | * Have time-stamps per read model to represent how recent the data is. That information can either be displayed to the user in the UI, and/or application services using that read model may have contracts stopping them from using data that is too old, | ||
| + | * Invalidate the read model if you have not received data within some defined time-span. If the UI or an application service tries to access that data, an exception will indicate that the supplied data is out of date. | ||
| + | In either case, the read model itself can use the abstract view and not care about the up-to-dateness of the data. **Additional** mechanisms will be put in place if stale supplier data becomes an issue. | ||
technology/domainmodel/boundedcontext/modelintegrity/customersupplier.1359652321.txt.gz ยท Last modified: 2013/01/31 18:12 by rtavassoli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
