DDD领域驱动设计

     

什么是自足系统(Self-contained Systems)?

149

自足系统(又称为自包含系统、自我独立系统,英文Self-contained Systems,简称SCS)是一种软件架构方法,SCS 包含自己的 用户界面、特定的 业务逻辑 和单独的 数据存储 。SCS.

利用大语言模型辅助领域建模

128 4K

对于生成式人工智能系统来说,在复杂的现实世界领域中航行是一项艰巨的挑战。不过,现在一种很有前途的方法照亮了前进的道路。通过首先深入理解数据,我们可以将原始输入转化为经过验证的结构,从而优化人工智能推理.

领域模型优先于数据库表

316 2 5K
由 Mark Seemann 发布:在讨论数据库,特别是 ORM 时,有些人会不言而喻地假设关系数据库是存储数据的唯一选择。许多程序员在关系数据设计方面非常熟练,他们在思考新问题时自然会使用这些技能。.

大规模实时机器学习处理架构简介

60 6K

Netflix 是迈向实时数据基础设施的公司的典范 ,这使得 Netflix 能够通过多种方式改善用户体验,例如改进“Trending Now”主屏幕上的推荐、快速测试生产中的更改以及最大限度地减少 .

微前端是模块化后的最终选择

192 1 5K

微前端应作为彻底解耦代码和依赖关系后的最后手段。分布式单体很难管理,并有可能在多个代码库中重新引入相同的问题。在拆分之前,需要进行彻底的重构,以尽量减少孤立部分之间的相互依赖。虽然拆分代码可以带来好处.

如何表达业务规则?用声明方式!

131 2K

下面这个比喻可以说明声明性规范与过程性规范之间的区别: 编写一个计算机程序。 在单独的卡片上注明每条语句。 将这卡片交给操作员执行。 确保程序运行正常,没有错误。 将卡片高高抛起。 按随机顺序捡起地上.

结合大语言模型灵活性和规则引擎可预测性

364 2K

大语言模型LLM系统(如ChatGPT)特点:灵活且惊人,但不可靠。规则引擎(如Drools)特点:稳定,可预测性、可跟踪性。使用langchain4j将大语言模型与业务规则引擎结合起来。训练有素的深.

什么是Context上下文?

538 1 2K
当你没有意识到上下文时,你永远就被置于上下文中!中国谚语:当局者迷、灯下黑、身在庐山不识庐山真面目。G.K.切斯特顿:每一个高级文明都会因为忽视显而易见的事情而衰败。Context Context; .

从贫血领域模型重构为充血领域模型

294 11K

贫血领域模型是一个没有任何行为、只有数据属性的领域模型。缺血(贫血、失血)领域模型在简单的应用程序中工作得很好,但如果您有丰富的业务逻辑,它们就很难维护和发展。业务逻辑和规则的重要部分最终分散在整个应.

什么是领域驱动设计?它是如何工作的?

142

与业务领域无缝集成的软件能为企业带来一系列强大的优势。它可以简化操作,增强以用户为中心的功能,并为利益相关者提供实时洞察力,以便快速做出深思熟虑的决策。DDD 是一种软件开发方法,擅长在领域专家和开发.

以患者为中心的医疗保健领域驱动设计

238 4K

让我们了解传统的电子健康记录 (EHR)。通常,EHR 被视为医疗保健提供商购买、部署并通常与其他系统集成的应用程序或系统。这些 EHR 以组织为中心,旨在满足采购实体的需求,并且重点关注流程和计费。.

构建软件最困难的部分不是编码,而是需求

107 2K

在所有关于人工智能的发展有多么令人惊叹的文章中,有很多人都在担心,我们这些软件开发人员可能很快就会失业,被人工智能所取代。他们想象所有的企业高管和产品研究人员都会绕过大部分或全部的软件开发人员,直接让.

DDD:从聚合到函数组合的改变

223 2 2K

来自OSKAR DUDYCZ的DDD变化旅程。这是我目前所处的进化阶段:我从经典聚合开始,遵循领域驱动设计和典型的面向对象战术模式。因此,将数据和行为封装在一个类中。然后,仅允许通过公共方法进行更改,.

fmodel-rust:使用Rust实现函数式领域建模的开源示例

132 1 4K
当您开发信息系统来自动化业务活动时,您就是在对业务进行建模。您设计的抽象、实现的行为以及构建的 UI 交互都反映了业务 - 它们共同构成了域的模型。这个项目可以用作库包,或作为灵感,或两者兼而有之。它.

Clean整洁架构的文件结构实现

391 1

下面是推特网友mjovanovictech对整洁架构(Clean Architecture)文件夹结构的方法。 专注于功能,而不是类型。  让我们以应用层为例:  应用 |__ FeatureFol.

微服务Saga分布式事务是一种反模式

324 3K

Saga通常被定位为处理分布式事务的更好方法。我认为讨论佐贺的优点和缺点没有意义,因为Saga根本不应该在基于微服务的系统中使用:如果你需要跨几个微服务的分布式事务,很可能你错误地定义和分离了领域。作.

好规则的标准:切实可行

317 3K

规则必须是具体和明确的,否则在遵守、确定和计数方面就无法做到有章可循。好的规则可以避免主观性和不可能。这些规则经过解释(深入研究),可以直接使用或应用。换句话说,好的规则是可以付诸实践的。在本文中,罗.

高内聚低耦合的集中决策设计

567 2

假设,我们正在构建另一个电子商务平台。其关键业务流程之一当然是处理订单。付款成功后,订单模块(域)必须异步调用仓库,准备购买的货物。然而,这些货物可能并不在那里。通常情况下,这不是什么大问题,因为我们.

概念、实体、数据三者之间区别?

469 1 5K
假设一个场景:与客户讨论开始新的工作:客户:我们的用户需要处理三种不同类型的任务:快速任务、复杂任务和监督任务。我们:它们之间有什么区别?客户:快速任务只是登记某人做了某事。真的很简单。我们:嗯。客户.

幽默:没有逻辑约束的微服务

485 2 2K
图中鸡蛋克和鸡蛋黄以及炉火三个微服务,如果为了吃一个煎鸡蛋,需要聚合这三个微服务调用。这是过于细分导致的问题,忽视了业务逻辑,如果煎鸡蛋是业务逻辑,那么为了完成这个目标,需要聚合这三个微服务。但是如果.

什么是团队拓扑? - martinfowler

540 1 2K

任何大型软件工作,如大公司的软件产业,都需要大量人员,而只要有大量人员,就必须想办法把他们分成有效的团队。组建以业务能力为中心的团队有助于软件工作对客户的需求做出响应,但所需的各种技能往往让这些团队不.

洋葱片架构 - odrotbohm

684 5K
15年的洋葱架构是时候整容了。自 Jeffrey Palermo 发布他的洋葱架构系列第一篇博客以来,已经过去了几乎整整 15 年。在那篇文章中,他总结了本质上构成Alistair Cockburn六.

Xapo银行去中心化的DDD架构实践分享 - martinfowler

673 10K

Xapo银行使用领域驱动设计、团队拓扑和架构建议流程三种方式实现企业架构的去中心化:软件架构在构建软件系统实践中的作用一直备受争议。在大多数组织中,你会发现某种 "架构 "功能,通常打着 "企业架构 .

DDD实践中如何设计上下文BC之间的映射关系?

379 5K

如何区分产品基础设施和技术基础设施 : 技术基础架构--不需要构建业务/产品背景,主要由开发人员使用。它不会立即影响用户体验,并且可以包含在一个特定的行会中。 产品基础设施——影响用户体验或有产品需求.

前端能整合后端的界限上下文BC吗?

344 2K

在理解域、子域、限界上下文、模块等之间的差异时遇到过困难?问题在问题空间中,也就是我们需要解决的问题中:Domain领域(例如,酒店)子域(例如,“预订”、“住宿”)。领域包含知识以及我们想要解决的一.

如何通过80%抽象建模防止单体走向混乱

533 9K
熵是一个普遍法则:如果不重新投入能量,一切都会趋于无序。软件也不例外。当进化发展受到时间和/或预算的限制时,系统就会变得“单体”。单体架构通常是对不一致抽象的意大利面条的委婉说法。Gusto已经建立了.

验证与业务规则的区别 - Mark Seemann

494 1 4K

验证是区别于业务规则的定义。本文提出了软件开发中验证的定义:介绍了我目前是如何区分验证和业务规则的。我发现这种区分是有用的,尽管这也许是一个因果关系颠倒的例子。我的定义是这样的:验证是一个决定数据是否.

关于领域建模的最佳书籍

798 1 4K

如果有人在我早期的职业生涯中告诉我,我将成为函数式编程的有力倡导者和函数式软件工程基础书籍的作者,我一定会觉得难以相信。函数式编程真的值得我为之奉献一生吗?然而,一旦我体验到函数式编程的纯粹之美,就再.

团队拓扑:模块化与划分团队相结合

523 9K

Martin Fowler的同事Matthew Foster描述了团队拓扑和领域驱动设计如何帮助组织扩展技术架构和团队结构,从而显着提高开发速度。模块化架构能改善软件交付吗?是的!但要注意一些问题。这.

康威定律:团队结构与软件架构之间的相互作用

507 2K
英国议会下议院在1941年的闪电战中被摧毁后,上议院就如何重建下议院展开辩论。一些人认为这是向马蹄形 "架构 "转变的机会,但丘吉尔团队主张他们保留 "对抗性的长方形架构"。他认为,这种布局本身就是英.