下面的SalesContext是继承了DBContext，这与楼主表达的意思一致，我想注意这个SalesContext中除了有Customers等实体模型，也应该存在这些实体相互调用的行为，否则对不起"Sales销售"这个称号，与销售有关的活动需要在这个场景(有界上下文)中表达吧？

Customer出现了多个版本，有的只需要三个字段，而有的则需要十几个字段，如果解决这个不同场景下同一个模型胖瘦不一样的问题呢？

下面的解决方案体现两种思维的解决办法，教材中是通过静态结构思维方式来解决，根据不同场景创建不同的类，比如顾客名单类CustomerReferenceList；Customer类继承Person类等等。这样设计出来的结果是几个Customer类让人眼花缭乱，产生歧义，其实这也是静态结构性思维的固有缺点。

如果我们换一种思维，认为这是Person在不同场景下扮演不同的角色，从而具备了不同性质字段，那么是否更加优雅和简单灵活呢？

[该贴被clonalman于2012-10-20 08:07修改过]

public class Variant
{
    public string Code;
    public string Name;
    public VariantCollection Inclusions;
}

public class Product 
{
    public string Code;
    public string Name;
    public ProductCollection Parts;
    public VariantCollection Variants
}

class ProductVariant extends Variant
{
    ProductCollection Exclusions;
    VariantCollection Selections;
    VariantCollection Combinations;
}

这是我实际设计模型代码实现大概样子,对产品的生产规格(BOM属性)与销售规格（SKU属性、其他属性）进行抽象,
分别用在生产与销售模块,功能需求上是实现产品BOM与商品SKU等，反映产品结构或商品组合，是两个不同需求，我设计上用同一个模型去实现，为区别不同的应用，设计上很自然的引入上下文场景。
[该贴被clonalman于2012-10-27 17:11修改过]

不知道有没有这种体会,当我们根据用户需求,分析的场景角色交互行为的后,
匆匆忙忙的进行实现,没有进不一步的设计抽象,功能上也是能实现,但存储的数据都是比较零散的,
在后续做分析决策的业务，就变的相当棘手，有时后需要对数据重新进行清洗整理或者我们的SQL语句异常的复杂。
如果设计做的好话的，原来分散的数据（原来可能在多张表的），可以呈现在相对集中的地方（如一张表中）。
这些集中的数据是不同场景下具有一定的演进关系，做分析决策时就相对容易一点。

[该贴被clonalman于2012-11-06 21:33修改过]

这个问题很有代表性，我以前也有思考，如何设计这些在不同场景下有微小字段区别的对象。

我是这样思考的：

这些有区别的字段有两种类型：
1.和具体场景有关的固有属性，比如BOM属性和SKU属性不同。
2.和场景活动产生的结果状态有关。

第一个是否可以使用组合引用原始Product方式实现，重新创建一个ProductBOM的对象？

第二个因为是业务活动的记录，属于事件-状态这种机制，可以专门设置状态对象作为Product的子对象来实现？

其实ProductVariant就是生产的BOM的规格描述,Product是产品家族
一个Product和一个ProductVariant实例可以对应一个SKU,
销售的商品SKU属性与生产产品规格有着天然的联系,这也就是我前面说的数据有一定的演进关系.

class EntityARepository
{
   public EntityA GetEntityAById(int id)   {      
      EntityA a = Context.Find<EntityA>(id);         
      a.OnEvent += context.Handle;  //这行代码能否自动实现？       
      return a;      
}

在对象重建实例化的时候，有没有程序自动实现对象内的事件与上下文的方法自动装配的机制，不引入annotation或其他领域不相关的技术或架构元素(Ioc容器除外)