4.模型驱动设计

一 领域 表示正在处理问题的区域。它是当前局面所切实面临的现实情况。领域模型是问题域的抽象。  

1.分析模型-业务模型 :描叙系统模型的构件集合。

2.代码模型 DDD强调保持代码模型、实现与分析模型、设计密切协同。要求两种模型都被描叙且同时使用UL 来达成。代码模型是领域模型的主要表现

二  模型驱动设计

  模型驱动设计是将分析模型绑定到代码实现模型确保两个模型保持协同并在演化期间可用的过程。

     1. 预先设计的问题

           1). 领域专家与业务分析员 创建分析模型【UML】然后交给开发人员

    2).开发团队初始代码与分析模型匹配

    3).基于技术术语的抽象演化模型,团队发现分析模型的问题并逐渐远离;分析模型没用了

    4).没有反馈回路,描叙性领域术语丢失没有揭示模型中的更深见解

    5).代码模型不在反映分析模型

   2.团队建模

  

三 通用语言

    UL是一个领域范围内的术语和概念。团队通过UL来协作沟通。它们也用于命名代码库中的类 方法 和命名空间。

   朔造UL

     1.确保语言一致性

     2.与领域专家创建一份领域术语表

   3.确保每个特定概念一个单词

    4.远离过载术语

    5.不要使用软件术语

    6通过UL 重构代码 规范类和命名空间

 

有效领域建模

 1.不要期望对真实情况完整建模,而是对问题域中有用的抽象建模。

 2.

 3.领域模型 都是暂时可用

4.限制抽象  仅为通用型采用抽象。一个抽象类或接口应该表示领域中的一个观念或者概念。在代码库中限制使用抽象。

 1)抽象在适合的层级

 2)对行为而非实现抽象

 3)尽早频繁的在代码中实现模型

  4)不断重构

转载于:https://www.cnblogs.com/RunStone/p/5831888.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值