深入理解领域驱动设计中的聚合
聚合模式是 DDD 的模式结构中较为难于理解的一个，也是 DDD 学习曲线中的一个关键障碍。合理地设计聚合，能清晰地表述业务一致性，也更容易带来清晰的实现，设计不合理的聚合，甚至在设计中没有聚合的概念，则相反。
聊一聊中台和DDD（领域驱动设计）
本次分享价值：本次分享主要针对中台、微服务和领域模型的理念、本质及其构建方法论进行探讨。对领域分析的价值所在就是寻求“千变万化”中相对的“稳定性、第一性”，然后通过合理的架构分析及抽象隔离业务的复杂度和技术复杂度，隔离业务领域的稳定性和易变性，从架构上精巧、快速的支撑业务的变化。
境外银行数据治理——思路分享
前言：在数据治理领域的文章大多都是从业务角度进行切入，本文从纯技术角度切入，介绍了数据血缘关系的图分析思路、领域建模层面构建中间层的思路。以及纯粹从词法分析和语法分析的统计学层面维度。
DDD领域驱动设计落地实践系列：战略设计和战术设计
通过前面的文章介绍，相信大家对于什么是DDD有了初步的了解，知道它是一种微服务的架构设计方法论，为我们解决如何建立领域模型，如何实现微服务划分等提供了方向和指导。但是对于如何具体落地使用DDD，可能大家还是一脸懵B的状态，因此从本文开始以及后面的文章将对如何进行DDD落地进行详细的阐述。在这其中还是会涉及到DDD中的一些重要概念，原本想着在一篇文章中介绍所有的概念，但是我觉得，概念总是在它该出现的时候出现才会让大家印象深刻，否则这些概念只是死板的概念，我们不清楚他为什么出现以及可以解决什么问题。
[半翻] 设计面向DDD的微服务
在DDD中，应用层依赖于领域和基础设施层，而基础设施依赖于领域层，但是领域层不依赖于任何层。
只在领域层编写业务规则和通用的领域知识，而应用层负责针对软件的目标来组合、协调领域层的业务规则。
领域层的领域实体、值类型、聚合根反映了真实业务的核心，需要用一种通用的语言来定义，这样不管应用层多么复杂，核心领域层自岿然不动。
领域层不能直接依赖与基础设施层，现代ORM框架一般都提出仓储模型来帮助领域层和技术设施层解耦。
组装式应用：数字化转型的关键
在数字化转型的大背景下，数字化相较于信息化，强调基于信息数据反哺业务，业务进一步促进系统的迭代优化。
对于数字化系统而言，只有支持灵活组装，才能覆盖不同行业，不同商业模式，不同业务场景的企业客户；只有做到互联互通，才能帮助企业打破信息孤岛，实现数据的沉淀以及后续的商业分析，实现反哺业务，进而帮助企业完成商业模式的优化或调整；只有支持自定义扩展，才能在业务迭代优化的同时，系统及时跟进，帮助企业业务快速落地，完成数字化闭环。