【领域驱动随想二】生产线标签打印

思来想去有点刹不住车，原来写博客也会上瘾，刚休息了三分钟又登上来了

【随想一】中的Carton类和Sheet类啥关系？

可以确定的是我把箱子扔到水里后里面的老干妈也都得被鱼吃了，看来这两者是生死存亡的好兄弟。

想起来以前看到的UML里面介绍两个类的关系时提到了聚合和组合，又想到了DDD里的聚合，细想一把啊，UML里的聚合是说咱俩有主从关系，但我没了你不一定跟着没了，比如汽车没了但轮子还可以装到别的汽车上跑；UML里的组合提到的是人与心脏的关系说人与心脏也是主从关系，但人没了心脏跟着也不跳了

我感觉DDD里的聚合更贴近UML里的组合

下个结论，等人来评：Carton和Sheet是DDD里的聚合，也是UML里的组合，Carton是聚合根（每箱产品都有唯一流水号），我假定Sheet是实体对象，因为你吃的臭豆腐有怪味儿问我为什么时，我不但得知道这是哪箱活儿，也得知道是这箱里的哪瓶坏了

   public class Sheet
    {
        //.....
        public string FullNum { get; set; }//唯一流水号
        //....
    }
 
    public class Carton
    {
        //....
        public string Num;//唯一箱体流水号
        private readonly List<Sheet> _sheets;//箱内数据
        //....
    }

我总是假定这个，假定那个，然后告诉各位只有这样模型才能成立，好吧，我承认我想到一个概念【限界上下文】，但我不知道此时是不是正在经历这个概念，在我完成的这个项目里，Carton对应的这箱臭豆腐到了仓库就不叫Carton了，因为在那里我喊他叫存货（Stock），但臭豆腐还是那箱臭豆腐，甚至流水号都没变

Carton和Sheet就是我心中的领域模型。我用它俩去验证一些概念。Carton的领域逻辑直接写在了类里面，大家都在提倡用富领域模型，我和大家一样，觉得洗洗更健康，否则应该是写着写着就回到三层了，不信你试试。我再举几个例子验证下这么设计的优势。前面提到用户是“扫描一片产品（Sheet）然后放入箱子，接着扫描第二片，再放入箱子……”，那如果扫到第20片时死机啦？怎么办？当然不能重新扫一遍,于是我在Carton类中引入了另一个方法AcceptSheets（sheets）方法用来执行本地缓存数据批量装入箱体的操作。

当从箱体里取最小生产日期的产品流水号、合计数量等操作时候，linq大显身手了，_sheets.Sum(x=>x.Qty)，_sheet.First()……爽的不亦乐乎，而且每一个语句都与客户的需求那么的贴近

箱子包装完成后干什么？当然是用胶带封箱了，所以Carton类中的Seal()方法是少不了的，Seal中跟着业务去释放一些东西

封完箱后标签也就跟着出来了，出标签这块我后期再说，是一个特别大的核心模块，集成了Zebra打印机ZPL语言

下一篇我会接着说打印前的逻辑：Carton的持久化