- android - RelativeLayout 背景可绘制重叠内容
- android - 如何链接 cpufeatures lib 以获取 native android 库?
- java - OnItemClickListener 不起作用,但 OnLongItemClickListener 在自定义 ListView 中起作用
- java - Android 文件转字符串
我正在考虑一个广告网站,用户可以在其中登录、发布新列表和搜索现有列表。我将把它作为我的第一个完全遵循 DDD 原则的项目。我以前从未在 Symfony 中做过任何 DDD。
以下是我对此的看法。您能否告诉我这是否正确以及关于更好方法的建议?
我可以看到两个域:用户和列表
搜索/显示/发布功能将存在于列表域中。在用户域中实时登录/注销。
SF3目录示例结构为
app/
ListingBundle/
src/
Listing.php
SearchService.php
ListingRepositoryInterface.php
Controller/
public/
ListingController.php
protected/
ListingController.php
Resource/
view/
public/
detail.twig.html
protected/
edit.twig.html
UserBundle/
src/
User.php
AuthService.php
UserRepositoryInterface.php
Controller/
public/
UserController.php
protected/
UserController.php
Resource/
view/
public/
login.twig.html
protected/
dashboard.twig.html
PersistenceBundle
src/
UserRepository.php
ListingRepository.php
我的主要问题是:
最佳答案
您在这里做出了错误的假设,即“我将使用 Symfony 框架以类似 DDD 的方式实现我的应用程序”。
不要这样做,Frameworks are just an implementation detail并为您的应用程序提供一种(或多种)交付方式。我的意思是应用程序在 Hexagonal Architecture 的上下文中.
如果您从我们的一个上下文中查看以下示例,您会发现我们的 ApiClient
上下文包含三层(顶级目录结构)。 Application(包含用例服务)、Domain(包含模型和行为)和Infrastructure(包含持久性和交付等基础设施问题)。我在这里专注于 Symfony 集成和持久性,因为这是 OP 最初的问题:
src/ApiClient
├── Application
│ ├── ApiClient
│ │ ├── CreateApiClient
│ │ ├── DisableApiClient
│ │ ├── EnableApiClient
│ │ ├── GetApiClient
│ │ ├── ListApiClient
│ │ ├── RemoveApiClient
│ │ └── ChangeApiClientDetails
│ ├── ClientIpAddress
│ │ ├── BlackListClientIpAddress
│ │ ├── CreateClientIpAddress
│ │ ├── ListByApiClientId
│ │ ├── ListClientIpAddresses
│ │ └── WhiteListClientIpAddress
│ └── InternalContactPerson
│ ├── CreateInternalContactPerson
│ ├── GetInternalContactPerson
│ ├── GetByApiClientId
│ ├── ListContacts
│ ├── ReassignApiClient
│ └── Remove
├── Domain
│ └── Model
│ ├── ApiClient
│ ├── ClientIpAddress
│ └── InternalContactPerson
└── Infrastructure
├── Delivery
│ └── Http
│ └── SymfonyBundle
│ ├── Controller
│ │ ├── ApiClientController.php
│ │ ├── InternalContactController.php
│ │ └── IpAddressController.php
│ ├── DependencyInjection
│ │ ├── Compiler
│ │ │ ├── EntityManagerPass.php
│ │ │ └── RouterPass.php
│ │ ├── Configuration.php
│ │ ├── MetadataLoader
│ │ │ ├── Adapter
│ │ │ │ ├── HateoasSerializerAdapter.php
│ │ │ │ └── JMSSerializerBuilderAdapter.php
│ │ │ ├── Exception
│ │ │ │ ├── AmbiguousNamespacePathException.php
│ │ │ │ ├── EmptyMetadataDirectoryException.php
│ │ │ │ ├── FileException.php
│ │ │ │ ├── MalformedNamespaceException.php
│ │ │ │ └── MetadataLoadException.php
│ │ │ ├── FileMetadataLoader.php
│ │ │ ├── MetadataAware.php
│ │ │ └── MetadataLoaderInterface.php
│ │ └── MFBApiClientExtension.php
│ ├── DTO
│ │ └── ApiClient
│ │ └── ChangeInternalContact
│ │ ├── ChangeInternalContactRequest.php
│ │ └── ChangeInternalContactResponse.php
│ ├── MFBApiClientBundle.php
│ ├── Resources
│ │ ├── config
│ │ │ ├── domain_services.yml
│ │ │ ├── metadata_loader.yml
│ │ │ ├── routing.yml
│ │ │ └── services.yml
│ │ ├── hateoas
│ │ │ └── ApiClient
│ │ │ ├── Application
│ │ │ │ ├── ApiClient
│ │ │ │ │ ├── CreateApiClient
│ │ │ │ │ │ └── CreateApiClientResponse.yml
│ │ │ │ │ └── ListApiClient
│ │ │ │ │ └── ListApiClientResponse.yml
│ │ │ │ ├── ClientIpAddress
│ │ │ │ │ ├── CreateClientIpAddress
│ │ │ │ │ │ └── CreateClientIpAddressResponse.yml
│ │ │ │ │ ├── ListByApiClientId
│ │ │ │ │ │ └── ListByApiClientIdResponse.yml
│ │ │ │ │ └── ListClientIpAddresses
│ │ │ │ │ └── ListClientIpAddressesResponse.yml
│ │ │ │ └── InternalContactPerson
│ │ │ │ ├── Create
│ │ │ │ │ └── CreateResponse.yml
│ │ │ │ └── List
│ │ │ │ └── ListResponse.yml
│ │ │ └── Domain
│ │ │ ├── ApiClient
│ │ │ │ └── ApiClient.yml
│ │ │ ├── ClientIpAddress
│ │ │ │ └── ClientIpAddress.yml
│ │ │ └── InternalContactPerson
│ │ │ └── InternalContactPerson.yml
│ │ └── serializer
│ │ ├── ApiClient
│ │ │ ├── Application
│ │ │ │ ├── ApiClient
│ │ │ │ │ ├── CreateApiClient
│ │ │ │ │ │ ├── ContactPersonRequest.yml
│ │ │ │ │ │ ├── CreateApiClientRequest.yml
│ │ │ │ │ │ └── CreateApiClientResponse.yml
│ │ │ │ │ └── GetApiClient
│ │ │ │ │ └── GetApiClientResponse.yml
│ │ │ │ ├── ClientIpAddress
│ │ │ │ │ └── CreateClientIpAddress
│ │ │ │ │ ├── CreateClientIpAddressRequest.yml
│ │ │ │ │ └── CreateClientIpAddressResponse.yml
│ │ │ │ └── InternalContactPerson
│ │ │ │ ├── Create
│ │ │ │ │ ├── CreateRequest.yml
│ │ │ │ │ └── CreateResponse.yml
│ │ │ │ ├── Get
│ │ │ │ │ └── GetResponse.yml
│ │ │ │ ├── List
│ │ │ │ │ └── ListResponse.yml
│ │ │ │ └── ReassignApiClient
│ │ │ │ └── ReassignApiClientRequest.yml
│ │ │ └── Domain
│ │ │ ├── ApiClient
│ │ │ │ ├── ApiClient.yml
│ │ │ │ └── ContactPerson.yml
│ │ │ ├── ClientIpAddress
│ │ │ │ └── ClientIpAddress.yml
│ │ │ └── InternalContactPerson
│ │ │ └── InternalContactPerson.yml
│ │ └── Bundle
│ │ └── DTO
│ │ └── ApiClient
│ │ └── ChangeInternalContact
│ │ └── ChangeInternalContactRequest.yml
│ └── Service
│ └── Hateoas
│ └── UrlGenerator.php
└── Persistence
├── Doctrine
│ ├── ApiClient
│ │ ├── ApiClientRepository.php
│ │ └── mapping
│ │ ├── ApiClientId.orm.yml
│ │ ├── ApiClient.orm.yml
│ │ ├── CompanyName.orm.yml
│ │ ├── ContactEmail.orm.yml
│ │ ├── ContactList.orm.yml
│ │ ├── ContactName.orm.yml
│ │ ├── ContactPerson.orm.yml
│ │ ├── ContactPhone.orm.yml
│ │ └── ContractReference.orm.yml
│ ├── ClientIpAddress
│ │ ├── ClientIpAddressRepository.php
│ │ └── mapping
│ │ ├── ClientIpAddressId.orm.yml
│ │ ├── ClientIpAddress.orm.yml
│ │ └── IpAddress.orm.yml
│ └── InternalContactPerson
│ ├── InternalContactPersonRepository.php
│ └── mapping
│ ├── InternalContactPersonId.orm.yml
│ └── InternalContactPerson.orm.yml
└── InMemory
├── ApiClient
│ └── ApiClientRepository.php
├── ClientIpAddress
│ └── ClientIpAddressRepository.php
└── InternalContactPerson
└── InternalContactPersonRepository.php
94 directories, 145 files
相当多的文件!
可以看到我是把bundle作为Application的Port来使用的(命名有点偏,应该不是Http
传递,因为在六边形架构的严格意义上,它是一个App-To-App Port)。我强烈建议您阅读 DDD in PHP book所有这些概念实际上都用 PHP 中的富有表现力的示例进行了解释(假设您已经阅读了蓝皮书和红皮书,尽管这本书作为独立的书使用,但仍然提供引用)。
关于php - SF3 文件夹结构中的 DDD,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38900497/
这里有一个很大的设计缺陷,但我无法解决它: 业务需要有点涉及,所以我会尽量保持简单。 我们有一张购物表和一张退货表。当进行退货时,我们必须找到与数据库中最早购买的退货匹配,并将其记录在“已应用退货”表
在我的家庭项目中,我遇到了确定域对象类型的问题。 领域:公交时刻表 限界上下文:路由(公共(public)交通基础设施,ctx1)、时间表(调度,ctx2) 对象: Station - 描述一个公交车
我有一个名为“产品类型”的值类型,它被分配给了一个产品。 (一个产品有一个产品类型) 为了允许用户从列表中选择类型,我将填充一个下拉列表。在哪里检索产品类型列表最合适?一个实现存储库模式的类? 编辑:
域这个词在 DDD 中究竟是什么意思?我一直在阅读定义……虽然我看到了域模型之类的东西并理解模型是什么 - 域模型是什么意思? 域实际上是什么意思? 谢谢 最佳答案 域是指您的应用程序解决的主题。 例
DDD 中的域模型应该与持久性无关。 CQRS 要求我为我不想在读取模型中包含的所有内容触发事件。 (顺便说一下,将我的模型拆分为一个写模型和至少一个读模型)。 ES 要求我为所有改变状态的事件触发事
Eric 在他的书中触及了 的主题。模块 很少。他也没有通过示例讨论模块结构与有界上下文的关系。限界上下文是否包含模块或模块包含限界上下文?当应用程序具有 DDD 时,它的可扩展性有多容易? 在我们设
前言 笔者于2021年入职了杭州一家做水务系统的公司,按照部门经理要求,新人需要做一次个人分享(主题随意)。 当时笔者对DDD充满了浓厚的兴趣,之前也牛刀小试过,于是就决定班门弄斧Show一下
上部分 模型驱动设计的构造块 为维护模型和实现之间的关系打下了基础。在开发过程中使用一系列成熟的基本构造块并运用一致的语言,能够使开发工作更加清晰而有条理。 我们面临的真正挑战是找到
3. 领域对象的生命周期 。 每个对象都有生命周期,如下图所示。对象自创建后,可能会经历各种不同的状态,直至最终消亡——要么存档,要么删除。当然很多对象是简单的临时对象,仅通过调用构造函数来创建
为了保证软件实践得简洁并且与模型保持一致,不管实际情况如何复杂,必须运用建模和设计的实践. 某些设计决策能够使模型和程序紧密结合在一起,互相促进对方的效用。这种结合要求我们注意每个元素的细节
大家好,我是 ddd 设计的新手,正在尝试使用这种在 C# 中工作的模式开发我的第一个应用程序 在我的应用程序中,我有一个包含子实体 Assets 的聚合合约,当添加或结算 Assets 时,我应该在
我正在尝试弄清楚如何使项目的一些消费者(业务客户)的不变量保持一致,他们对同一版本的聚合根有自己的要求。让我们以客户为例,提出假设性问题以满足以下愚蠢的逻辑: public class Custome
我见过一些具有实体值对象表示的 DDD 项目。它们通常显示为 EmployeeDetail、EmployeeDescriptor、EmployeeRecord 等。有时它包含实体 ID,有时不包含。
我试图了解如何表示某些 DDD(域驱动设计)规则。 遵循蓝皮书约定,我们有: 根实体具有全局身份并负责检查不变量。 根实体控制访问,并且不会被其内部结构的更改所蒙蔽。 对内部成员的 transient
我对 ddd 中的验证方法有疑问。我已经阅读了相当有争议的意见。有人说这应该在实体之外,其他人说这应该放在实体中。我试图找到一种我可以遵循的方法。 例如,假设我有带有电子邮件和密码的 User 实体。
寻找有关如何解决此问题的建议,并了解域驱动设计是否真的是这里的最佳模式。 我的客户正在重新构建其几近过时的工具和服务堆栈。客户是一个快速扩张的电子商户。它的核心产品是它的大型电子商务网站。围绕该网站,
我很难找出实现依赖于数据库中存储的数据的业务规则验证的最佳方法。在下面的简化示例中,我想确保用户名属性是唯一的。 public class User() { public int Id { g
情况: 要处理域事件,Jimmy Bogart proposed 一种将事件存储在聚合中的方法。 在我看来,这是一种非常方便的方法。但是,域服务中的域事件怎么办? 域服务不应该有状态(stateles
我正在处理遗留项目,试图改进项目结构。我的问题是我应该如何组织代码结构。我看到两个选项: #1 business-domain / layer app/ ----accout/ --------app
根据 DDD 原则,所有处理与特定聚合根对象相关的实体的 CRUD 操作都应该由聚合根进行。 但是我们如何从 aggr 根中仅更改实体的单个属性?我们应该在实体中有 setter 方法吗?这些方法应该
我是一名优秀的程序员,十分优秀!