领域模型的思路是对象树和业务职责划分边界，即，方法 依附于相应的对象，具体构造哪些对象取决于方法组的逻辑。
领域模型的上下游聚合，上下游子域，上下游域是根据业务流的分层，一个块或一个域所处的层是不确定的，确定的只是他在流中的位置，它是一切分层的纵向切面的投影视图。
编程的分块在于抽象的概念。概念是编程的可见疆域，功能模块则是守护区域的卫兵，合理的概念划分和强大清晰的模块设计，将使该区域产生支撑全局的物质力量。
如果程序的结构清晰设计会伤害到效率，一般而言优先考虑结构设计，效率可以在其他层面上优化，结构一旦混乱，则往往会数十倍的损失效率而不自知。
概念从模糊到清楚有若干层次，开发时总会有若干概念处在不同水平的模糊状态。不要试图一次搞清楚所有的事情，应将不清楚的事情划领域定接口，然后忽略之。
在团队中针对逻辑需求和优化需求及涉及当前团队的关注度和自身代码推进的需求，将提案设置不同的优先等级，有些问题不必关注，照例模糊化。
在领域范围内足够合理的抽象，自能后期扩展。
合理的系统程序员在自身域内并不知道对方的工作，也只是模糊的知道一个域和接口，程序员往往会产生是自己负责了绝大部分工作的错觉。当这种错觉产生（本人往往也知道这是错觉）意味着程序的领域和模块已经进行了合理的划分。