识别服务与操作的边界划分试探法

确定服务层边界上该提供哪些操作，由服务层客户（首要是用户界面）的实际需求决定——既然用户界面是为支撑各类用例设计的，识别服务层操作的起点自然是用例模型和界面设计。作者的经验是：企业应用里多数用例其实是针对领域对象的单调CRUD操作（创建/读取/更新/删除），CRUD用例与服务层操作之间几乎总是存在一一对应的关系，只是应用的职责还要处理这些操作之外的协调——除了增删改查本身，往往还要通知其他人或触发别的集成应用，而协调这些响应、保证它们原子化正是服务层操作该干的事。至于该怎么把这些操作归拢进不同的”服务”抽象，没有必须遵守的硬规定，只有一些模糊的经验法则：应用足够小时，一个以应用自身名字命名的抽象就够了；应用较大时，作者习惯按垂直切分的”子系统”来组织，每个子系统对应一个以其名字命名的服务抽象；此外也可以按领域模型的划分方式命名（如ContractService、ProductService），或者按应用行为的主题来命名（如RecognitionService）。可迁移启发：划分服务边界这类”没有标准答案”的设计决策，与其追求一步到位的完美分类，不如先认清它本质是经验法则，按手头应用的规模和领域结构灵活套用几种常见命名思路（子系统/领域对象/行为主题）里最贴切的一种。