通常，有很多的应用声称是用领域驱动开发（DDD）构建出来的，并且有一个领域模型，但是这个模型实际上却仅仅包含业务实体，甚至于分离数据和逻辑的数据传输对象和服务都混合在了一起，其中也分不清业务和基础设施逻辑， Gabriel Schenker 分享了从事咨询和软件架构以来的个人经验。在具有消息处理的应用中，很少用业务领域中名称来命名消息，反而采用了以_update_ 或_modify_ 结尾的这种统称。
Schenker 目前是一位首席软件架构师，他说这一点儿都不夸张，他本人就常常发现早期的新应用就是这么构建出来的。Schenker 认为，这一现象的主要原因就是由于缺乏知识。
Schenker 强调说，如果采用 DDD 开展工作可以参考 Eric Evan 的 DDD 专著，但其中的所有模式的重要程度并不是安全相同的，特别是要注意这本书中后面部分的 DDD 基础，有些已经得到了 Evans 的充分肯定。与这些策略模式形成鲜明的对比的是，上半部分中的战术模式重点关注于实现的细节。
Schenker 建议说，当使用 DDD 开始一个新项目时，首先应和领域专家对业务领域达成一致的理解，把讨论中的术语抽取出来，大家共同商定创建一个通用的词汇表，在 DDD 术语中这叫做统一语言。让领域专家识别彼此间分离的区域，把复杂的领域予以分解，从而创建子领域或有边界的上下文，嘿嘿，这又是另一个DDD 术语。
Schenker 还告诫说，不要以数据模型开始创建一个以数据为中心的世界。他坚信，孤立的数据什么都不是，数据若想有意义就离不开逻辑，而且还要注意上下文的变化，所以，上下文和逻辑应该是 DDD 的主要关注点。专注于数据还有另一个风险，数据库最终会用于集成，实际上这从另一方面增加了上下文间的依赖。Stefan Tilkov 也于近期建议避免采用通用的数据模型。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论