我是SOA（面向服务的体系结构）的新学习者我对以下场景有一个问题：
在公司（Mycompany）中，销售团队就在那里（这是业务能力的技术权威 - 其中销售是业务能力）。该公司决定创建2个产品，如Mycompany.Photos.com和Mycompany.Grocery.com。对于两个网站，他们需要销售能力，即订单接受能力。
因此，销售团队必须为两个网站工作。因为，这两个网站都需要销售能力。
现在问题是销售团队是否应该为每个网站和2个不同的端点创建2个不同的数据库？
例如：
如果销售团队最初有一个队列“Mycompany.Sales.Endpoint”并且它收到CreateOrderCommand。它处理CreateOrderCommand，在sales DB中创建订单并发布OrderAcceptedEvent。当他们只支持一个网站时。如果他们开始支持具有相同端点的两个网站，那么销售如何区分天气，此订单是针对Mycompany.Grocery.com或Mycompany.Photos？我们应该将Mycompany.Sales.Endpoint拆分为2吗？销售团队是否应该了解Photo网站订单和Grocery网站订单？
我能想到的一个答案是：
销售人员将有2个端点说“Mycompany.Grocery.Sales.Endpoint” Mycompany.Grocery.com BusinessComponent和MycompanyPhotos的“Mycompany.Photos.Sales.Endpoint”。
即使它们属于同一个销售范围的上下文，它也可以拥有2个业务 组件（BC）？我是否正确，这是否是我们扩大销售团队将支持两种产品的销售能力的方式？
我很抱歉这条长信息。我找不到任何解释这个的捷径。
答案 0 :(得分：2)
服务是业务能力的技术权威。
如果你能够区分任何一个系统的订单，但是你不能，那么你可能正在为多个业务能力建立一个“技术权威”。
除此之外，服务可以包含许多组件。而不是专注于技术问题，专注于业务问题，看看你是否可以解释。但是像Stackoverflow这样的平台，在问题和比率方面的比例为1：1。对于像这样的问题，回答可能不是正确的媒介。
答案 1 :(得分：2)
我认为更好的方式来考虑这种情况，你实际上有两家公司 - 一家在杂货店业务，具有所有相应的功能，以及照片业务。即使这两家公司＆＃34;碰巧分享相同的公司文件，你真的不应该把它看作一个单一的实体。