• DDD不是为完美主义者而生
  • 红色幽默 发表于 2017/2/27 18:00:00 | 分类标签: 领域驱动设计 设计模式
  • 追寻完美设计是从一开始就伴随着领域驱动设计(DDD)的常见问题,但DDD不是为完美主义者而生的。最近在阿姆斯特丹的DDD欧洲会议上,Eric Evans在其演讲中指出,为了停止这种追求,你需要对如何创建设计良好但并不完美的软件有一些概念,他还给出了一些这些年使用DDD的示例。


    最早的DDD图书的作者Evans指出,限界上下文的最初目的是让我们认识到我们开发软件的开发环境相当复杂,它涉及许多遗留系统和其他的外部系统,以及可能带来影响的其他团队。在围绕软件的一部分的上下文中,你拥有概念上的一致性,在此特定的词总是意味着相同的事情。作为开发人员,你应该能够识别出你是否处于上下文的边界内,然后需要遵循特定于该上下文的规则。边界令你可以自由定义适用于那里的规则;不仅包括使用的术语,还包括架构和开发过程。Evans指出,微服务应该是自治的,可以成为良好的限界上下文,但强调这一点并不意味着服务总是限界上下文,有时开发人员会把服务理解为限界上下文。


    Evans认为康威定律(Conway's law)和限界上下文的概念之间存在一定的关联,他想创立一些东西来应用该定律。他举了一个例子,在一个系统中有两个上下文:一个负责信用卡,另一个负责现金帐户。这里我们在组织架构、子域和限界上下文之间取得了协调一致。但是现在,为关注细分市场进行业务重组,将商业帐户与个人帐户分离,并为每种帐户创建了一个团队。两个上下文保持不变,现在两个团队都在这两个上下文中开展工作,时而发生的冲突意味着他们要协调他们的工作。他将这比喻为三足赛跑,为了提高速度,协调是必要的。在这种情况下,可能的风险是产生一个杂乱无章、随意堆砌的系统(Big ball of mud),Evans看到的一个常见原因是对软件开发缺乏清晰的管理。一个可能的解决方案是建立一个新的边界,使用防崩溃层(Anti-corruption layer)。


    有时一个模型并不完备,不足以处理所要处理的所有情况。不是要创建一个能够处理更多情况却感觉很笨拙的模型,而是可以选择创建一个函数来处理模型未能处理的情况。这样的函数和许多if-then-else语句一起工作,和任何高层概念保持距离以避免创建另外一个模型。不应该使用不完备的或难以理解的抽象。Evans指出,最好使用if-then-else语句而不是错误地认为要创建一个优雅的模型。创建这样的模型可能最终连能工作的模型都找不到。他认为追求一个好的但并不完美的设计是关于权衡的很好的例子。


    Evans不建议非得等到模型完美了才去使用它,那样的话我们将无法发布任何软件。我们必须忘掉这样的想法,即只要你在前期投入额外的时间去做设计,从长期来看就一定能得到回报。然而,我们不能走向另一个极端,只是堆砌一些可怕的东西并发布出去。如果我们在模型中有意识地做一些权衡,并具备一定的技能,在对已有模型不满意时知道该怎么做,将会得到更好的结果。

  • 请您注意

    ·自觉遵守:爱国、守法、自律、真实、文明的原则

    ·尊重网上道德,遵守《全国人大常委会关于维护互联网安全的决定》及中华人民共和国其他各项有关法律法规

    ·严禁发表危害国家安全,破坏民族团结、国家宗教政策和社会稳定,含侮辱、诽谤、教唆、淫秽等内容的作品

    ·承担一切因您的行为而直接或间接导致的民事或刑事法律责任

    ·您在编程中国社区新闻评论发表的作品,本网站有权在网站内保留、转载、引用或者删除

    ·参与本评论即表明您已经阅读并接受上述条款

  • 感谢本文作者
  • 作者头像
  • 昵称:红色幽默
  • 加入时间:2013/6/13 0:00:00
  • TA的签名
  • 这家伙很懒,虾米都没写
  • +进入TA的空间
  • 以下内容也很赞哦
分享按钮