本文以一名研发人员的视角，介绍了在架构师确定使用领域驱动设计方案的前提下，如何通过DDD的相关概念，落地到具体的代码实现

Hello，这里是爱 Coding，爱 Hiphop，爱喝点小酒的 AKA 柏炎。 好久没有写过文章了，上一次还是签约作者的赶稿。稿子赶完之后，每天的糟心事太多了，一直提不起兴趣来创作。 不过快到年底

从接触领域驱动设计的初学阶段，到实现一个旧系统改造到DDD模型，再到按DDD规范落地的3个的项目。对于领域驱动模型设计研发，从开始的各种疑惑到吸收各种先进的理念，目前在技术实施这一块已经基

MVC 旧工程腐化严重，迭代成本太高。DDD 新工程全部重构，步子扯的太大。这是现阶段在工程体系化治理中，我们所面临的最大问题；既想运用 DDD 的思想循序渐进重构现有工程，又想不破坏原有

本文与大家一起学习并介绍领域驱动设计DDD，以及为什么我们需要领域驱动设计，它有哪些优缺点，尽量用一些通俗易懂文字来描述讲解领域驱动设计，本篇

我认为一份完整开发文档应该至少具有七大维度，每个维度描述系统的一个侧面，组合在一起最终描绘出整个系统

充血模型是DDD分层架构中实体设计的一种方案，可以使关注点聚焦于业务实现，可有效提升开发效率、提升可维护性

前言 之前我写过一篇关于DDD文章，大白话之辩论DDD，阿里面试中台化理解，这次心血来潮是因为最近在看掘金的一个关于领域设计的课程，然后下面谈谈我读后感，以及在我现实项目里面究竟用到哪些内容，最后还有

DDD领域建模被各个大小厂商提起并应用，而每个人都有自己的理解，本文就是针对小白，系统地讲解DDD到底是什么，解决了什么问题，及一些建议和实践。本文主要是思想的一种碰撞和分享，希望能对朋友们有所启发或