问题：代码如何和领域模型保持一致？C语言能清晰的表达领域模型吗？
第一个问题：代码和模型保持一致，需要掌握用编程语言实现模型的“标准方式”，并具备写出自注释代码的能力。
第二个问题：能，但是要掌握模块化C的设计和编码方式。
以下作为补充，提供给感兴趣的同学。
我们知道模型是一种抽象，面向对象建模得到的模型结果是经过选择的对解决问题有价值的概念、关系和约束的集合。
确实，面向对象编程语言可以方便的表达领域模型。例如通过类可以表达领域概念；通过interface表达接口和服务；通过private可以封装属性和行为；通过构造和析构函数进行对象生命周期管理；通过继承和引用可以表达泛化和组合关系等。因此选择面向对象语言来实现领域模型是非常自然的。
遗憾的是并不是所有实践领域建模的同学对面向对象编程都是良好掌握的！见过不少同学能把所有单实例和多实例的领域概念都用单例表达；无论泛化还是组合关系都能用共有继承来实现；无论引用对象的生命周期早或者晚于自己都用指针来表示... ； 在这种实现下，即使做了领域建模，用了面向对象编程语言，模型和代码也没有直接关系。
其实每种面向对象语言都有表达模型的“标准方式”，很早的时候建模工具就已支持自动从模型生成指定编程语言的骨架代码。现实中我们很少用这个功能，主要有以下原因：
1）大部分情况下，模型图都很难表达所有的实现语义（做不到、或者成本太高）。所以自动生成的代码是不完备的，还需要人工修改代码以补充缺失的实现细节；
2）针对图的编辑、重用，重构、版本管理，往往不如直接搞代码来的高效；
3）每当模型变化后，从模型图重新生成的代码又要和已实现代码进行merge，合并成本大，效率低；
4）最后，对于像C/C++这样比较底层或者复杂的语言来说，从模型到代码的自动生成效果会更差，不具备实用性。
因此在现实的情况下，为了追求效率，程序员们绝大多数时候还是直接用代码实现和演进模型。
但是手动实现，不代表可以随意实现！遵循一些从模型到代码的最佳实践，或者叫做“实现模式”，会让代码更加清晰的表达模型，甚至做到“望文生义”，降低代码和模型的同步成本。
表达模型的实现模式，不同的编程语言会有区别。以下是我总结的C++实现模型常用的实现模式。限于篇幅就不再展开了，对C++比较了解的同学应该都看的懂。
那么用C语言能否很好的实现领域模型呢？
如前面所说，用编程语言表达模型，需要为对应的编程语言建立起一套表达模型的“实现模式”。
虽然C语言被认为是一门过程化语言，但并不是说C语言就没有表达领域概念和关系的能力。Robert C. Martin在《Clean Architecture》中甚至认为"C语言的限制其实更少，可以做出更灵活的设计选择"。
Anyway，我们不去争论编程语言的优劣，我们来看看如何在C中表达领域概念和关系。
相比用C做过程化设计，现代化C编程更推崇使用模块化C的设计方法。模块化C要求用一个“.h”和一个“.c”文件组合实现一个概念（类似一个面向对象中的类）。“.h”文件中包含该概念对应的结构体或者句柄，还有该概念支持的API声明；而“.c”文件中包含API的函数实现，以及用static修饰的内部共享状态与私有函数实现。
如下代码表达了Storage的概念，可以看到里面包含Storage的类型定义与API。所有API的第一个参数是Storage自身，加const表示该API是只读的，否则是可写API。
#include "base/status.h"
typedef struct Storage
{
int capacity;
int type;
} Storage;
/* Read-only */
double storage_charge(const Storage* storage, int months);
int storage_level(const Storage* storage, int months);
/* Writable */
Status storage_promote(Storage* storage);
模块化C中一般用结构体的包含关系或者指针引用表达模型中概念之间的组合关系。而模型中的泛化关系则需要用到C语言的“函数指针结构体”的设计技巧，具体在编码的时候还需要区分泛化关系背后的调用是无状态还有有状态的。
如下代码示例如何通过action_create创建具有泛化关系的Action：
#include "point.h"
typedef enum {
ALERT_ACTION, CLEAN_ACTION, MAX_ACTION,
} ActionType;
/* Abstract Interface */
typedef struct Action {
void* data;
void (*exec)(void* data, const Point* point);
void (*destroy)(void* data);
} Action;
/* Factory Function */
Action action_create(ActionType type, const Point* points, int numOfPoints);
介绍了如何用C语言表达概念以及概念间关系后，我们来看看生命周期管理。
领域驱动设计强调对领域对象的生命周期进行显示的建模和管理。
在不考虑持久化的情况下，领域对象生命周期一般起始于构造函数，结束于析构函数。但是在C语言中结构体没有显示的构造和析构过程，所以生命周期管理一般对应于结构体内存的分配与回收。
在嵌入式场景下，经常使用全局变量按照业务规格在静态内存区预占内存，这导致了程序员很容易把领域对象的生命周期管理和用于内存预占的全局变量耦合在一起。
全局变量是缺乏清晰的生命周期语义的，它起始于进程初始化，销毁于进程退出。而领域对象的生命周期的开始和结束是却是有清晰的业务指示的。如果代码对领域对象的所有访问都直接使用它对应的全局变量，就会导致领域对象生命周期管理和内存管理混淆在一起。再加上全局变量带来的代码耦合问题，最终会导致代码难以理解和维护。
对于这个问题，我们可以借鉴领域驱动设计中提出的Factory和Repository的概念来承担领域对象的生命周期管理职责，并对领域对象的内存管理方式进行封装，对外屏蔽领域对象的创建和存储的技术细节。其它所有需要使用领域对象的代码都应该通过Factory或者Repository获得领域对象的句柄或者结构体指针，这样核心的模型代码就和内存管理方式等基础设施进行了解耦，也避免了和全局变量的耦合，提升了代码的可维护性与可理解性。
更多关于模块化C以及如何用C语言表达模型的方式，可以借鉴《C现代编程》和《嵌入式C设计模式》中的内容，希望随后有机会能就这个话题更系统性的总结一下。
追求代码本身就是模型的直接映射是领域驱动设计强调的一个核心。如果一个更好的解决方案只是存在于设计文档中，并没有在代码中实现，那么它是没有产生实际价值的。因此，保持持续重构，当有更好的解决方案的时候，就找机会重构进代码里。只有被代码真实反映的模型才是当前软件中真正的模型！
