Timeline for When bounded contexts and "microservices" collide. A distributed systems dilemma in diagram form
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 16, 2021 at 18:55 | comment | added | allmhuran | I suppose you could also call it "option 5 with a point to point ETL rather than a pub-sub model". Ie, option 5 with the "alternative" described in red in the diagram. But I don't think that's quite right, because in option 5 the messages are stored independently, whereas in your solution they're "derived" from data sitting directly in CRM. | |
| Aug 16, 2021 at 18:46 | comment | added | allmhuran | ... This is not a "decoupled message queue being subscribed to by the orders system" - so it's not 4, 5, or 6, it's just a "buffer", if you prefer to call it that, entirely within the responsibility of the CRM system's extension. So a process within the responsibility of the CRM system (ie, a process which reads directly from the CRM extension) is pushing data directly to an Order API of some kind, via some kind of ETL process, with no shared domain logic. | |
| Aug 16, 2021 at 18:44 | comment | added | allmhuran | You have different specific technology components in your solution description, but from an architectural point of view, it's functionally the same as option 2: The domain logic rests entirely in the system of record (orders), and the CRM system is calling some kind of supported write interface on the Orders system - whether that's a set of rest API's, or stored procedures, or insertable views, or whatever. There's a queue in between - ok, if you don't want to call it a queue, it's, an "ordered list of things that will be removed once processed in some way"... | |
| Aug 16, 2021 at 10:58 | comment | added | Kind Contributor | It is not the same as Option-2, because I am describing a "direct database" approach with a background process. The only similarity is if you choose to not use the Db View and instead insist on sourcing from the Order's Service-Api. There are many differences that I am describing in my answer. | |
| Aug 16, 2021 at 10:56 | comment | added | Kind Contributor | "Connect to the orders database" is ideal, because data can be replicated and business-rules can be enforced via a Db View. A DB View is an API. A Restful Endpoint can also be an API. The former is preferable, but if you must, a Restful Endpoint (or other service-layer API) is also workable. I did not say "stored procedure". (Continued for your last question) | |
| Aug 16, 2021 at 10:52 | comment | added | Kind Contributor | "it's a view acting with the functionality of a queue, is it not?" - generally yes, but not completely. You can easily find similarities between things, but differences are essential to understand. Consider that with a View, the data-conditions can change, it's possible for an "item" to be "removed" from such a queue without processing it. For instance, a user can cancel their order before the "queue item" is processed, meaning the item will never be processed. (next question to be continued in the next comment...) | |
| Aug 16, 2021 at 4:49 | comment | added | allmhuran | Sure, it's not literally a queue, but it's a view acting with the functionality of a queue, is it not? Ie, anything returned by this view is a deal is "queued" to be turned into an order, but has not yet been. Regarding the second part of your answer, I'm not sure what you mean by "connect to the orders database", but also "works via API". The API would typically be a component above the data layer. If you mean the business rules are in, say, stored procedure code on the order db, then that is functionally the same as my option 2 diagram, except the "API" is in the database. | |
| Aug 16, 2021 at 4:44 | comment | added | Kind Contributor |
NoDealOrders is not a queue. View_NoDealOrders is a view on OCRM database. It's a simple VIEW that checks whether a DealOrder record has been created yet - it's a Driving View for a microprocess. The microprocess connects to the Orders database and works according to order rules (via API or Orders Db View). As I concluded in my answer, I'm using a lot of imagination, because I don't have full specs. So my answer only demonstrates on example where the CRM system is finding an Order from the order system to align with the Deal. The order would need to already exist. @allmhuran
|
|
| Aug 15, 2021 at 20:27 | comment | added | allmhuran |
I missed your answer, my apologies, your comment has brought it to my attention. You wrote that a process connects to the order database and works according to order rules. I take it that NoDealOrders is a queue of orders in CRM that have yet to be "confirmed" by the order system. But how is CRM operating "according to the order rules"? These rules are domain logic defined by the Orders system that CRM must either implement itself (diagram 5), or somehow copy from the orders system (could be possible, eg if the order system publishes domain logic as a nuget package) (diagram 4)
|
|
| Aug 14, 2021 at 11:48 | history | edited | Kind Contributor | CC BY-SA 4.0 |
Added diagram for my answer, and made it clear it's very different by saying "Option X"
|
| Aug 14, 2021 at 11:14 | history | edited | Kind Contributor | CC BY-SA 4.0 |
Grammar/spelling improvements
|
| Aug 14, 2021 at 11:13 | comment | added | Kind Contributor | I also have a more specific answer for your statement - "Others say it's a domain which can have multiple bounded contexts, which are more granular" - see todd-hubers.medium.com/the-size-of-a-microservice-b9e6bc90475. Basically, the answer is that you should "start" with the less granular scope first, then cluster to create a cohesive boundary. (But my answer still stands as a stronger foundation for building software) | |
| Jan 2, 2021 at 3:08 | history | answered | Kind Contributor | CC BY-SA 4.0 |