首页 > 代码库 > 领域驱动模型和以数据为中心模型的一些思考

领域驱动模型和以数据为中心模型的一些思考

2024-07-10 15:34:10   224人阅读

假设有如下业务逻辑：
我要搬到新地方去工作。  
代码1:
class Player
{
public:
    void setAddr(string name);
    void setJob(string job);
private:
    string _name;
    string _job;
}
代码2:
class Player
{
public:
    void changeAddr(string name);
    void changeJob(string job);
private:
    string _name;
    string _job;
}
 
看以上两个例子，貌似只是接口名字不同，但是其实這里面包含了以数据为中心的模型和领域驱动模型的区别
 
1.以数据为中心的模型，将关注点放在数据上，這样当数据属性很多时，客户程序很难判断一个业务需要用到多少
数据属性，并且容易造成代码的失忆症（很难通过代码判断真实的业务逻辑），這时候就需要花费大量的精力去做
数据到业务逻辑之间的映射。上面代码1就是以数据为中心的模型的一个例子，与其说上面是提供业务逻辑服务，
不如说它是一个数据持有器，因为两个接口没有真正的业务意义，只是提供了一种改变或者存储数据的方式。
2.领域驱动模型提倡以业务逻辑为中心，将关注点放在对象行为即业务行为逻辑上，主张体现最有价值的业务逻辑。
上面代码2就是领域驱动模型的一个例子。两个模型的关注点决定了在定义搬家换工作這样的行为时是采用setAddr，
setJob這样的代表数据而无实际业务价值的行为还是采用changeAddr和changeJob這样的代表实际业务逻辑的行为
的区别。
思考:
1.但是如果以实际业务价值定义对象行为，那么如何解决多个业务逻辑的本质行为相同时，所造成的行为泛滥呢？
比如说我失业了或者退休了，這时候需要置_job为空，那么用changeJob已经不能代表這个业务逻辑了，需要用到
loseJob()或者retire(),但是這几个操作的本质都是设置job，這样就衍生出三个job操作而本质都是setJob的行为。
這个可能就需要团队定义通用语言来解决了。本人觉得应该将应用层分为应用逻辑支持层和应用逻辑实现层。支持
层定义一些通用的逻辑对象和行为，实现层负责组合通用逻辑对象和行为以完成逻辑功能。但是這里的通用对象和
行为也不是没有实际业务价值的贫血症对象和行为，需要团队创建领域模型的通用语言。
2.但是贫血症对象和行为在一个完整的项目中，真的可以完全去掉吗？如果我要创建一个几个项目公用的通用模块
呢，怎么办？领域模型如何解决這种通用性和业务价值之间的矛盾？或者说是不是这种通用模块需要定义自己的业
务范围和逻辑，而不是局限于该项目？
 
继续学习中。。。


联系
我们