clonalman
2012-10-27 16:56
关于有界上下文,从技术架构来看,基本是公说公有理,婆说婆有理,盲人摸象,只摸到了大象的局部而已,既然是领域驱动设计,还得回归领域的实例来说明.

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;
}
<p>

这是我实际设计模型代码实现大概样子,对产品的生产规格(BOM属性)与销售规格(SKU属性、其他属性)进行抽象,

分别用在生产与销售模块,功能需求上是实现产品BOM与商品SKU等,反映产品结构或商品组合,是两个不同需求,我设计上用同一个模型去实现,为区别不同的应用,设计上很自然的引入上下文场景。

[该贴被clonalman于2012-10-27 17:11修改过]

clonalman
2012-10-27 20:25
上述Product虽然在不同场景下的属性是一样的,

但每个属性在不同场景下的业务含义都不一样,这是设计抽象的结果。

不知道有没有这种体会,当我们根据用户需求,分析的场景角色交互行为的后,

匆匆忙忙的进行实现,没有进不一步的设计抽象,功能上也是能实现,但存储的数据都是比较零散的,

在后续做分析决策的业务,就变的相当棘手,有时后需要对数据重新进行清洗整理或者我们的SQL语句异常的复杂。

如果设计做的好话的,原来分散的数据(原来可能在多张表的),可以呈现在相对集中的地方(如一张表中)。

这些集中的数据是不同场景下具有一定的演进关系,做分析决策时就相对容易一点。

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

banq
2012-11-07 12:02
2012-10-27 20:25 "@clonalman"的内容
这些集中的数据是不同场景下具有一定的演进关系 ...

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

我是这样思考的:

这些有区别的字段有两种类型:

1.和具体场景有关的固有属性,比如BOM属性和SKU属性不同。

2.和场景活动产生的结果状态有关。

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

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

clonalman
2012-11-08 21:09
2012-11-07 12:02 "@banq"的内容
第一个是否可以使用组合引用原始Product方式实现,重新创建一个ProductBOM的对象?第二个因为是业务活动的记录,属于事件-状态这种机制,可以专门设置状态对象作为Product的子对象来实现? ...

其实ProductVariant就是生产的BOM的规格描述,Product是产品家族

一个Product和一个ProductVariant实例可以对应一个SKU,

销售的商品SKU属性与生产产品规格有着天然的联系,这也就是我前面说的数据有一定的演进关系.

clonalman
2012-11-27 05:57
模型是明确指向,BoundedContext可以做为隐含概念,象Eric书里的DDD例子

模型是抽象指向,可对应多个现实模型,BoundedContext应的该显式描述出来

clonalman
2012-12-15 06:28
c#代码

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

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

--------------------------------------------------------------------------------

文件配置还是把Entity、BoundedContext也扔到Ioc中?

[该贴被clonalman于2012-12-15 06:39修改过]

[该贴被clonalman于2012-12-15 06:41修改过]

clonalman
2013-01-29 05:24
2012-12-15 06:28 "@clonalman"的内容
a.OnEvent += context.Handle; //这行代码能否自动实现? ...

axon:

    @Override
    public T load(Object aggregateIdentifier, Long expectedVersion) {
        T aggregate = doLoad(aggregateIdentifier, expectedVersion);
        validateOnLoad(aggregate, expectedVersion);
        return CurrentUnitOfWork.get().registerAggregate(aggregate, eventBus, saveAggregateCallback);
    }
<p>

axon是在AggregateRoot和UnitOfWork这里做文章

.net下,只要实现一个Event Broker应该是能自动装配了,

这样对象里就有了Property、Method和Event了,领域对象就丰满了。

[该贴被clonalman于2013-01-29 05:34修改过]

[该贴被clonalman于2013-01-29 05:38修改过]

猜你喜欢
2Go 上一页 1 2