查询 (Query)
上图中，可以看到Query不是通过DB来查询，而是通过一个专门用于查询的Read DB（上图中的Cache，它不一定是数据库，但为方便起见，下面统称Read DB），Read DB中的表（方便起见，暂且认为这个Read DB是一个RDBMS）是专门针对UI优化过的，例如里面可能会有LatestProductListModel(ProductId, ProductName, Price, BrandName, AddedTime)、BestSoldProductListModel(ProductId, ProductName, TotalSold)这样的表，分别表示最新的产品列表，销量最好的产品列表（它们其实就相当于是View Model）。LatestProductListModel中有一个BrandName的字段，注意，不是BrandId，因此，对于界面中的查询，几乎全都可以通过SELECT * FROM [TABLE]这样的SQL语句来实现，可能有少数Where，但基本没有Join，这对于界面的加载速度绝对是有利无弊的（其实也是在用空间换时间）。
命令 (Command)
业务逻辑大部分都发生在写入的时候，例如用户购买商品提交订单时，我们要验证库存，用户信息订单数据是否有效等。如果从传统DDD的角度看，Command类似于Application Service，用户的命令（如提交订单）会以Command的形式得到执行，而Command中也不会带有业务逻辑，Command中做的事情基本上是：通过Repository得到相关的领域对象，调用某些领域服务（Domain Service）执行一些操作（业务逻辑都将保留在领域模型中），然后执行Commit或SaveChanges之类的方法提交改动，之后，相关的数据就会写入到Write DB中（图的DB，下文统称Write DB）。需要注意的是，UI上的查询都是查Read DB，而不是Write DB。
