对领域模型的一些看法

领域模型建立，似乎是从内往外的设计，完成后，最终暴露出一些对外服务
面向需求的用例，好像是从外往内的设计，完成后，最终能建立一套业务模型

如果2个都不能少的话
领域模型可以包含：业务实体/业务逻辑/业务缓冲，这三者都直接对外提供服务
实体就是实体了，它是否应该包含某种业务逻辑，应该看
该业务逻辑是不是需要，“知道”别的对象，
或者知道别的对象，也至少不会去修改别的对象的状态，那么就应该属于实体的逻辑，否则单独拿出来
业务逻辑就是业务逻辑了，凡需要“知道”/修改 一个以上对象状态的逻辑，就在这里拉
业务缓冲，主要为了面向需求，
前面的说的业务实体和业务逻辑，应该是个比较稳定的业务内核，但是也不能保证一百年不变，也不能保证满足100个客户需求，
当出现一种需求，业务内核没有这种功能，就先放到业务缓冲里，业务缓冲可以不区分实体这些，可以面向过程，可以直接连数据库，总之以最快的速度完成客户需求，等以后有时间进行重构，如果多个客户都提出了类似需求，或者时代变迁，业务内核已经老化了，那么就把业务缓冲的一些部分，沉淀到业务内核中

如果上面3个直接对外提供服务，就不需要应用服务这一层了，不过可以搞请求层和应答层
请求层，就是为视图绑定一些服务，有些mvp的概念，每个视图都应该有自己的请求层，为自己绑定服务
应答层，做数据渲染用，当视图激发绑定的服务后，服务的返回将到达应答层，
如果服务返回的数据对象，和视图上需要渲染的对象一致，那这一层可以技巧性的作的很简单
如果2个对象不一致，那应答层就需要，既知道数据对象是什么意思，又知道被渲染的对象是什么意思，然后组织起来

“当出现一种需求，业务内核没有这种功能，就先放到业务缓冲里，业务缓冲可以不区分实体这些，可以面向过程，可以直接连数据库，总之以最快的速度完成客户需求”

对于复杂的业务，这种方法不可行。 简单孤立的业务还可以，无论是否为核心业务，都需要有一个具体的实现框架。

分领域，千万不要包罗万象，lz说不可能满足100个客户，我是赞成的，因为这是把共同点抽象出来满足更多的客户的同时，带来的就是更多的配置的复杂，就好像SAP，我觉得一般做软件，找到个平衡点就好，走极端付出的是巨大的。