首先： 服务化是什么，为什么要服务化
服务化是一种将业务、功能或流程抽象为服务的设计方法，通过服务之间的协作和调用来实现系统的整合和复用。它可以提高系统的可维护性和扩展性，主要用来构建分布式系统。
然后：
怎样服务化
SOA 和 微服务 都是实现了服务化的、比较典型的架构风格。
SOA的出现是为了解决功能复用的问题，将一些通用的模块提取出来做成服务。但是SOA对于通用模块的设计没有设计核心原则，因此在对应需求变化等变更时，会产生可维护性变差，通用模块需求影响能力不足等问题。
微服务架构与DDD配合使用从理论上解决了SOA这方面的问题。基于微服务的 服务设计 一般要要满足下面的 原则 ：
1>单一职责，一个服务要从属于一个领域或者子领域，也就是说一个服务做的事情理论上应该是一句话能说清楚的。
2>服务自治，一个服务要具备独立的业务能力和运行环境，依赖包括存储也是独立的，有一套完整的流程，可以当成一个项目来对待。
3>服务组合，多个小型服务可组成一个更大的服务。
4>服务契约，API应该明确和清晰地定义其接口、协议、通信方式、版本管理和SLA。
在微服务架构中，技术上的 关键是 服务治理。服务网格本质是服务治理的一个范畴。微服务架构给出了服务拆分的基本原则，DDD给出了拆分的一个参考方向：面向领域拆分，也给出了一些基本的拆分模型，比如DDD四层架构、洋葱型架构。实际使用过程中也可以 面向流程拆分或者面向功能拆分。典型的面向功能拆分的架构是微内核架构。这两个拆分方向与DDD并不冲突。
项目实施时，还需要解决拆分粒度的问题。这个问题DDD中没有给出明确的解决方案。
拆分粒度可以从成本维度和质量维度两个大方向来考虑。
成本维度
考虑资源占用情况，虚机来做成本高，如果公司容器化做得好，粒度可以细一些，通过基础设施来提高整体资源利用率。
考虑人力情况，多人维护一个服务，沟通成本高；一人维护多个服务，开发成本高。理论上，一个中级工程师独立维护一到两个服务是比较理想的。
考虑变更情况，如果两个服务经常一起变更，分开成两个服务成本相对较高。
质量维度
考虑服务治理等基础设施支持，如果基础设施支持足够完善，提供标准的RPC调用、完善的链路追踪、监控、数据可视化支持，粒度可以细一些，反之，基础设施不完善，粒度粗一些，整体服务质量更可控。
考虑性能消耗情况，拆分服务会增加通信成本，这个成本是否可以接受、与收益是否成正比或者是否可以通过其他的技术手段降低影响。
考虑部署速度，如果粒度太粗，一个服务服务器数量可能会增加，发布时间可能会很长；如果粒度太细，也可能因为要部署多个应用发布时间增长。要做好权衡。
考虑应用规模和业务量，项目初期，建议粗分，然后演进。上量之后，一个原本简单的业务，量级上的质变也可能需要拆得很细来解决稳定性、拆解场景的复杂性。
考虑 高可用要求上，高可用等级不同也可能拆分成不同服务，比如核心应用三地六机房部署，非核心应用双机房部署。
