Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

10
  • 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) Commented Aug 14, 2021 at 11:13
  • 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) Commented Aug 15, 2021 at 20:27
  • 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 Commented Aug 16, 2021 at 4:44
  • 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. Commented Aug 16, 2021 at 4:49
  • "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...) Commented Aug 16, 2021 at 10:52