配置文件指定分片部署role例子：

 cluster { seed-nodes = [ "akka.tcp://posSystem@127.0.0.1:2551"] log-info = off sharding { role = "shard" passivate-idle-entity-after = 10 s } }

10、设计后端执行命令后返回的结果类型

11、设计一套POS前端的命名规则：因为有关POS过程的事件持久化是以persistenceId辨别的，所以一个POS编号应该有一个对应的persistenceId，所有这个POS编号的事件都以对应的persistenceId来存储。我们先跳到ClusterSharding是如何动态地构建和部署ShardRegion和entity的：ClusterSharding是通过两个函数extractShardId,extractEntityId来对应ShardRegion和Entity实例的。用一个shardId去调用ShardRegion，如果不存在就用这个Id构建一个。ShardRegion是个actor，那么这个Id应该就是它的ActorPath.name。同样ShardRegion也会用一个entityId去构建Entity。这个entityId也就是Entity的ActorPath.name了。而从ActorPath结构来看：ShardRegion是Entity的父辈。最终，我们可以用父子关系的ActorPath.name来代表persistenceId，如：

 // self.path.parent.name is the type name (utf-8 URL-encoded) // self.path.name is the entry identifier (utf-8 URL-encoded) but entity has a supervisor
  override def persistenceId: String = self.path.parent.parent.name + "-" + self.path.parent.name

如果考虑的全面些，我们可以把区域zone,门店shop,部门dpt,POS机合并成一个唯一的Id：

1位zoneId+3位shopId+2位dptId+4位POSId => 10位POSUID 如1001019365

12、用actor来模拟POS前端。店号与shardId, 机号与entityId对应。暂时用以显示后端执行指令结果。

以上这12个关注点算是我编程前的一些思路和备注。然后就开始写示范代码了。经历了好几遍周折，这段CQRS的C部分是越写越细、越复杂。主要是想把这个例子做成一个将来可以落地的项目（刚好有朋友公司他们提供零售IT解决方案，需要一个平台化android前端POS解决方案），自不然又不断考虑前端移动客户和后端CQRS的Q部分如何实现的问题，这时在一个局部功能的实现里需要照顾到全局的功能需求，往往把应该在其它部分实现的功能都放到这个C部分代码中来了。所以还是应该先从整体系统考虑的更具体、全面些才行。

一开始，我的主要注意力是放在persistenceActor的状态变化，也就是收款机开单操作过程的维护方面。我犯的第一个错误就是老是担心在后面Q端（读端）能不能实现客单项目内容管理，所以复杂化了event数据结构，总是希望为Q端提供完整的信息来支持对客单项目内容的管理。实际上C端和Q端各自的功能应该是：C端主要负责把所有的操作动作都记录下来，Q端把这些动作恢复成交易项目，形成客单内容，然后管理整个客单状态。C端只维护客单的开始、结束状态。至于这张单项目内容的修改、调整则应该是放在Q端的。这样一来，正如本篇标题所述：还是需要多想想，有全局思路。下面是我重新整理的一些想法：

1、整体考虑前端POS机客户端、C端、Q端：前端接收收款员操作动作及应对动作所产生的结果如显示、打印等。C端负责动作的数据采集。Q端负责客单交易内容的构建和管理

2、从C端角度考虑：需要向前端返回每个动作产生的结果，使前端有足够的信息进行显示、打印小票等。如实向Q端反应具体操作动作，提供客单状态如新单、结束、单号等Q端管理客单状态必要的信息。

3、C端POSHandler是个cluster-sharding-entity persistenceActor with backoffSupervisor。对应的前端POSRouter是客户端请求入口，是个cluster-singleton，能实现热插拔、热转换。POSRouter可以通过cluster-load-balancing在routees上运行Q端。

4、C端有以下几种状态：登陆前、开单中、单结束。C端程序主要是处理这几种状态里的操作