摘要：问：如何提高编译速度？答：减少一次需要编译的代码量，目前想到的有两种思路：1：修改解决方案的属性配置，取消勾选不常修改的项目的“生成”复选框。2：采用插件化的架构，每一个插件弄一个解决方案，一次只编译一个插件。 阅读全文

摘要：问：什么情况下使用 struct ？答：使用 struct 有几个前提（必须全部满足）：容忍 struct 本身的限制，如：不能继承。值语义。足够小（<=16字节）。如果 struct 不作为参数就行传递，可以不考虑“足够小”这个限制。问：为什么要“足够小”？答：.NET 默认按值传递参数，class 拷贝的是 reference（16 字节），而 struct 拷贝的是其自身，因此 struct 不能设计的太大，否则性能上会受到影响。 阅读全文

摘要：问：Domain Event 和 C# 中的 Event 有啥区别？答：C# 中的 Event，事件、监听者列表和事件发布器是由一个类型承担，事件源和监听者之间的生命周期耦合在一起，C# 帮你提供了一个语法糖 以支持这种模式。DDD中的 Event，事件、监听者列表和事件发布器是由三个类型承担，事件源和监听者之间的生命周期没有耦合在一起。DDD 中的事件监听者，还会分为两类：内部事件监听者和外部事件监听者，当事件发生时，内部事件监听者会立执行，外部事件监听者会在工作单元提交后执行。如果考虑事件溯源，还需要考虑如何持久化事件，以及外部事件发布的顺序问题。 阅读全文

摘要：问答部分问：领域服务的职责是什么？答：夸聚合实例业务逻辑。没办法合理放到实体中的其它业务逻辑。问：领域服务的设计原则是什么？答：用来组织业务逻辑。面向业务逻辑。细粒度。内部视图看系统。一个请求对应多个服务的多个方法。服务之间会存在依赖。问：应用服务的职责是什么？跨Bounded Context业务逻辑。DTO转换。事务AOP、权限AOP、日志AOP、异常AOP。外部系统访问：邮件、消息队列。应用服务的设计原则是什么？答：用来封装业务逻辑。面向用例。粗粒度。外部视图看系统。一个请求对应一个方法。服务之间互不依赖。其它资料DDD：应用层的三种组织风格。 阅读全文

摘要：问答部分问：如何修改领域模型？答：一般来说我们有两种选择，这两种选择也是两种价值观的体现（乐观和悲观）。第一种：使用UI传递过来的DTO在应用层重建Domain Model，然后执行修改，DTO更多的表达了一种结果。1 public class Application2 {3 public void Update(DTO dto)4 {5 var entity = this.AutoMap(dto);6 7 repository.Update(entity);8 }9 }第二种：使用Repository从Database中重建Domain... 阅读全文

摘要：问答部分问：仓储实现为什么在基础设施层？答：领域模型包含三种元素：实体、值对象和服务，这三种元素都可以以某种形式使用仓储，为了保证领域的纯粹性，我们引入了仓储接口，仓储的具体实现在基础设施层中，仓储接口位于领域层中。问：仓储实现能在领域层吗？答：技术可以，从关注点分离上讲，仓储实现和领域模型有不同的关注点，视乎没有任何必要将他们划分到一个层，问：仓储接口能在基础设施层吗？答：技术上不可行（.NET中是如此），仓储接口依赖领域模型，领域模型依赖仓储接口，会存在双向依赖，在.NET中会编译不通过，在其他平台也不见得是好的选择。参考文章http://www.cnblogs.com/happyfram 阅读全文

摘要：问：枚举和常规的值，到底哪种更符合程序使用？答：肯定是根据不同的场景，做出不同的选择。如果是不同的值需要不同的逻辑，肯定是枚举好一些。如果只是表示某个取值范围且这个范围会动态变化，用常规的值 + 数据字典会方便很多。 阅读全文