摘要: 将实体和值对象在一致性边界之内组成聚合乍看起来是一件轻松的任务,但在DDD众多的战术性指导中,该模式却是最不容易理解的。 让我们首先来看看一些常见的问题。聚合只是将一些共享父类、密切相关联的对象聚集成一个对象树吗?如果是这样,对于存在于这个树中的对象有没有一个实用的数目限制?既然一个聚合可以引用另一 阅读全文
posted @ 2024-03-12 06:54 Ruby_Lu 阅读(204) 评论(0) 推荐(0) 编辑
摘要: 通过模块完成设计 在DDD中,模型中的模块表示了一个命名的容器,用于存放领域中内聚在一起的类。将类放在不同模块中的目的在于达到松耦合性。在DDD中的模块并不是一个通用的存储区域,因此对其进行适当的命名是重要的。事实上,模块名是通用语言的重要组成部分。 在设计模块时,有几条简单的原则: 我们应该将模块 阅读全文
posted @ 2024-02-28 20:57 Ruby_Lu 阅读(10) 评论(0) 推荐(0) 编辑
摘要: 领域中的服务表示一个无状态的操作,它用于实现特定与某个领域的任务。当某个操作不适合放在聚合和值对象上时,最好的方式便是使用领域服务了。有时我们倾向于使用聚合根上的静态方法来实现这些操作,但是在DDD中,这是一种坏味道。 我们应该尽量避免在聚合中使用资源库。 什么是领域服务(首先,什么不是领域服务) 阅读全文
posted @ 2024-01-31 21:00 Ruby_Lu 阅读(282) 评论(1) 推荐(0) 编辑
摘要: 值对象虽然经常被掩盖在实体的阴影之下,但它却是非常重要的DDD部件。值对象的常见例子包括数字,比如3、10和29.51;或者文本字符串,比如“hello world”;或者日期、时间;还有更加详细的对象,比如某人的全名,其中包含姓氏、名字和头衔;再比如货币、颜色、电话号码和邮寄地址等。当然还有更加复 阅读全文
posted @ 2024-01-24 07:37 Ruby_Lu 阅读(235) 评论(0) 推荐(1) 编辑
摘要: 开发者趋向于将关注点放在数据上,而不是领域上。这对于DDD新手来说也是如此,因为在软件开发中,数据库依然占据着主导地位。我们首先考虑的是数据的属性(对应数据库的列)和关联关系(外键关联),而不是富有行为的领域概念。这样做的结果是将数据模型直接反映在对象模型上,导致那些表示领域模型的实体包含了大量的g 阅读全文
posted @ 2024-01-03 07:25 Ruby_Lu 阅读(540) 评论(0) 推荐(1) 编辑
摘要: DDD的一大好处便是它并不需要使用特定的架构。由于核心域位于限界上下文中,我们可以在整个系统中使用多种风格的架构。有些架构包围着领域模型,能够全局性地影响系统,而有些架构则满足了某些特定的需求。我们的目标是选择合适于自己的架构和架构模式。 在选择架构风格和架构模式时,我们应该将软件质量考虑在内,而同 阅读全文
posted @ 2023-12-18 06:53 Ruby_Lu 阅读(395) 评论(1) 推荐(3) 编辑
摘要: 一个项目的上下文映射图可以用方式来表示。比较容易的一种是画一个简单的框图表示两个或多个限界上下文之间的映射关系。该框图表示了不同的限界上下文在解决方案空间中是如何通过集成相互关联的。另一种更详细的方式是通过限界上下文集成的源代码实现来表示。 上下文映射图为什么重要 上下文映射图主要帮助我们从解决方案 阅读全文
posted @ 2023-11-23 07:10 Ruby_Lu 阅读(435) 评论(2) 推荐(0) 编辑
摘要: 总览 从广义上讲,领域(Domain)即是一个组织所做的事情以及其中所包含的一切。商业机构通常会确定一个市场,然后在这个市场中销售产品和服务。每个组织都有它自己的业务范围和做事方式。这个业务范围以及在其中所进行的活动便是领域。当你为某个组织开发软件时,你面对的便是这个组织的领域。这个领域对于你来说应 阅读全文
posted @ 2023-11-22 06:55 Ruby_Lu 阅读(449) 评论(0) 推荐(3) 编辑
摘要: 设计不只是感观,设计就是产品的工作方式。 我们的目标应该是创造一个可观测的、可伸缩的、组织良好的软件模型。 DDD同时提供了战略上的战术上的建模工具。 我能DDD吗? DDD首先并不是关于技术的,而是关于讨论、聆听、理解、发现和业务价值的,而这些都是为了将知识集中起来。如果你了解公司的业务,那么你至 阅读全文
posted @ 2023-11-10 06:50 Ruby_Lu 阅读(80) 评论(0) 推荐(1) 编辑
摘要: 阅读全文
posted @ 2023-10-31 06:53 Ruby_Lu 阅读(34) 评论(0) 推荐(0) 编辑