關於斷言的解惑：
個人理解為斷言和無副作用函數都是用於解決邊界影響的方式。
在软件中，操作分为：命令和查询，命令就是能够使 系统状态发生改变的操作，如增删改等操作。这些操作都可能需要有副功能，如希望增删改完成后还要返回一些结果，这些主要功能之外的副业，也称为边界影响(side effect)。一些传统过程经验的程序员经常喜欢搞“一机多用”，喜欢将很多功能揉合在一起。
大多数操作会调用其他操作，造成任意深度的嵌套，这样形成一个树形结构的调用关系，这就容易使我们很难 预测调用一个操作会产生什么样的结果，调用一个操作变得谨慎，甚至战战兢兢，虽然Ioc或DI container使 得这种嵌套关系的管理变得容易，但是不能保证每个操作本身的设计能降低复杂性，后者就是我们现在关注的。
为什么我们调用一个操作时会变得小心，因为这个操作设计时可能不执行主要功能，还有其他副功能，这些 副功能可以认为是一种多余副作用，解决办法很简单：设计这个操作时消灭副作用；如果不能消灭，就将其 分离显式分离并单独表达出来。
所以，我们设计增删改命令和查询功能时，尽可能分离它们到不同操作中实现，不要在增删改命令执行的同时 返回任何领域数据。
如果边界影响不能通过设计避免，那么我们就直面它，在增删改等命令执行同时返回数据，当这样做的同时， 我们就使用断言assertion来约束我们这样的设计，通过断言能够易于使用单元测试Junit等工具测试。从而 保证你的命令简单有规则。
总之还是那句有些哲学意义的话：对于边界功能，首先要去除它，如果不能回避它，就承认它，但是同时会约束它。
边界影响主要的是Service接口怎么做的问题。在实际项目中，Model和Service是相互结合不断重构的。那么Model和Service粒度是如何界定的？