认识达内从这里开始

认真做教育专心促就业

合肥达内Java培训领域驱动设计应用方法分析

发布：合肥达内软件培训
来源：互联网
时间：2022-12-28 09:05

领域驱动设计是目前大多数软件编程开发程序员都在学习的一种软件开发方式，今天我们就通过案例分析来简单了解一下，领域驱动设计应用方法分析。

合肥达内Java培训领域驱动设计应用方法分析

我想谈论的架构风格与微服务非常相似。它是关于将单体应用分离为多个独立的服务应用，或者从一开始就在边界上下文(DDD概念)的帮助下单独开发它们。

有许多资源都强调了微服务叙述中更细粒度的服务的优点。越来越多的文章、博客和其他内容是关于陷阱和在向细粒度服务过渡之前或过渡期间应该拥有的安全网的。我将尽量不重复微服务或其他支持元素的好处，这些是迁移到这样的体系结构中所需要。我不想强调结果服务的“小型”性质，而是想强调如何通过应用领域驱动的设计概念来更好地分离这些服务。

让我们使用一个真实的示例来实现我们的想法-借记卡/信用卡获取域。这个领域可以(不幸的是，很多时候都是这样)作为一组单体应用来实现。我们拥有多个应用的唯一原因是由于不同的应用中的存在严格的技术限制(例如希望执行批处理)。

我所看到的大多数成功的架构都认识到，通过数据库进行集成是一种糟糕的实践，因为它使技术应用和业务职责之间的界限变得模糊，使业务逻辑泄漏到数据库中,并通过添加更多的应用服务器来阻止水平扩展。因此，以单体应用的的服务集成的形式发展到更好的架构。

现在，应用之间的界限更加清晰了。但是，您可以看到，仍然存在隐藏的数据库交互，这一次是在各个应用内部发生的。我称它们为隐藏的，因为通常一开始它们通常很难被注意到。随着时间的流逝，代码的纠缠将使原先分离的业务流程人为地关联起来，并在业务开发中引入更多的摩擦，因为这种共置托管需要联合部署单独的功能，这可能会减慢速度。

如果您幸运地有一个领域模型来指导的话，则领域建模可帮助您识别和分离复杂的实现。如果您还没有现有应用的域模型(在大多数情况下通常是这样)，则无需遍历代码以了解不同的职责，而是构建域模型并将功能映射到手边的应用可能是一个更好的方法。这既能节省时间，又能避免被细节淹没的风险。此外，如果业务与开发团队之间存在差距(这可能是域模型初不存在的主要原因)，那么讨论域模型并映射到现有应用的功能将有助于缩小这一差距。

我们设计演进的下一步是将域边界分离反映到我们的架构以及边界上下文中。一个域具有多个边界上下文意味着在同一域中可以有多个服务应用运行。有了适当的域模型，潜在的分离点就更可见了，这使我们可以从潜在的更细粒度的应用中受益(诸如单独发行和版本控制的好处，具有更多功能驱动的纯服务端点的潜力等，其中大多数已经在微服务文章中进行了讨论)。尽管许多微服务讨论都围绕技术不可知论和开发规范(避免/破坏整体)，但对于我们大多数人所从事的应用而言，非常有价值的一项是领域和设计方面。一旦过渡到微服务架构(借助域模型)，DDD和更细粒度的服务便可以协同工作、相互支持。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。

< 上一篇：合肥达内培训软件测试的基础是什么

下一篇：合肥达内培训零基础入门Java编程需要掌握哪些编程心理学 >