进城务工人员小梅某项目组提出了关于“有关原子层粒度设计”的如下问题：
1）有关原子层粒度的设计问题：
目前****在分布式架构层面已经明确了取消组合层对原子层的微服务调用，而用SDK接口实现，避免分布式事务一致性问题。但是在原子层的设计粒度上最近还在讨论摸索，确定相关的原则。目前拟采取的原则是，尽可能减少组合层对原子层的调用频次，尤其是对同一个中心的连续业务处理(如多个表先后连续操作)需要封装在一个原子层接口中。
由于****的老的C语言代码，部分交易业务处理上较为复杂，因此很难保证同一个中心只调用一次，但是也希望通过粒度优化减少调用频次，在业务层面上进行封装，体现原子层接口业务含义，实现上避免将原子层仅作为DAO层/CRUD数据操作层。希望提供****专家提供对于原子层接口设计粒度的意见作为参考。
结合个人的一点思考，回复如下，供大家批评指正。
这个问题非常大、涉及到的点非常多、可以讨论很久，具体需要结合系统现状、人员素质、高层认知及迭代策略权宜；但是，有以下的几个大原则可供参考：
（1）一定要注意摒弃贫血模型，始终站在领域、场景的角度，适当在直觉和概念上参考DDD（领域驱动设计）的理念，微服务究竟多微、如何拆分是依托于领域、伴随着对领域的划分自然而然产生、自然而然分层（也可能分多层）的。所谓原子层的设计粒度一定不是简单地面向DAO层面的贫血模型式增删改查，而更应该倾向于数据模型及领域业务流程所共同体现的领域行为；
（2）一定要意识到，除了“面向服务编排为核心的共享服务层”以外，“面向领域流程为核心的共享领域层”更为重要和艺术，在这个共享领域层之上才能构建出所谓的数据中台、业务中台及流程中台，而不是试图直接在“面向服务编排为核心的共享服务层”上直接堆砌；
（3）组合层对原子层的调用频次问题、是否涉及分布式事务的问题，同样可以在直觉上参考DDD，在合理地领域化之后，对于领域对象、领域行为的使用通常能够依托“面向领域流程为核心的共享领域层”来消除和减少对大规模分布式事务的强依赖——SDK化是一种最简单的处理方式，即通过SDK把某些领域行为包在了一起，而这些行为能够被包在一起也许恰恰本身就说明应该通过某些层次的抽象、通过其他层次集成在一起，而不应该把其下的CRUD粒度的服务作为“微服务”直接暴露出来，甚至还供其他系统使用——服务一定是面向解决领域问题的，而不是无脑地暴露给别人由别人去组织更大概念上的业务逻辑；
（4）我们强调的DDD更多地是在直觉和概念上，去指导结合当前的代码结构、人员认知等在代码层次、模块层次、系统层次等方面进行因地制宜地设计，而不是照搬DDD的某些实现（事实上，也是搬不了的）；
（5）“共享领域场景”是一个逻辑上的概念，可轻可重、可有可无，需要结合对应领域/场景等等直觉概念的具体情况权衡，例如：轻则通过jar包集成以LPC（本地方法调用，通常不涉及大规模的分布式事务）的方式实现、中则RPC远程方法调用、重则是彻底的服务化。至于如何、通过什么进行LPC、RPC、服务化则是实现层面、技术框架层面的问题。
转载时请保留出处，违法转载追究到底：进城务工人员小梅 » 有关原子层粒度的设计问题的一点思考