我希望能够以编程方式注销所有登录用户.如何在某些事件上强制注销所有用户？
如果你在CRD的DDD应用程序之上有一个REST层,你会让REST层吐出域模型(就数据而言)(比如GET)吗？
我正在考虑Spring-security 3.0,Spring的ACL过滤发生在post(api call)操作中.有两个问题: -
我已经看到了解决方案,其中每个查询都附加了在数据库级别进行过滤的acl查询,但是由于它在授权问题上污染了业务逻辑,这看起来很丑陋,是否有任何方法/框架可以透明地进行数据库级别的acl过滤？我喜欢spring-securities通过配置/注释以声明方式强制执行安全性的整体方法,从而直接从安全相关逻辑中删除代码,但我认为它在性能问题上失去了这一点
我在这里和其他论坛上看到的很多问题都有一个常见的反应,就是"你不需要为此做DDD.它是一个简单的CRUD应用程序,DDD是一种过度工程".
嗯,我是DDD的新手,我觉得DDD中有很多元素具有普遍的吸引力,可以全面使用,无论你的应用程序是否复杂,都需要DDD.例如,应用程序的分层,DDD识别的不同工件等等.可能从基础知识开始,然后承认贫血模型,然后工作/重构尽可能多的纯度.
这种方法听起来不错吗？
或者你会说在每个应用程序的设计中是否有一个基本的选择,无论是否采用DDD方式,是一种"全有或全无"的选择？
更新 (提供更多上下文,以回应下面的休的评论)
我正在围绕现有的RuleEngine类应用程序构建一个webapp,基本上是CRUD和一些验证,不变量,然后是部署过程.规则创作和语义检查由一段独立的代码完成,我将其作为CRUD的一部分调用,并且我的代码中没有任何语义特定的逻辑.我正在尝试将DDD用于此应用程序,但我发现它可能不够复杂到适合DDD范例.没有为该域定义普遍存在的语言,即除了命名所涉及的实体集之外,该语言还不够专业.我听说我的领域专家在创建,编辑,删除实体方面发言.
为REST GET查询指定投影是否违反REST原则和/或它是一个好习惯？
考虑一个api /person?fields=fname,lname, address,这可能是因为人是一个大模型而且对于我目前的要求我只需要给定字段的值(比如我正在创建一个UI网格)
我正在学习DDD，并有一个基本问题：
似乎在工厂，丰富的域模型，（CRUD的）Create，Read，Update存储库都已处理完了，但是删除又如何呢？在删除实体的地方可能存在一些业务逻辑？RepositoryImpl（属于基础结构）层不应该麻烦自己检查那些不变式，它的工作是从底层数据存储中删除给定的实体。这似乎与工厂的意图截然相反，但是DDD没有像“ kill”工厂那样的删除对象。
假设有一个用户可以删除的Order实体，但是直到它处于“已完成”状态，才可以删除，因此请求删除的客户端repo.delete(ent)应获得Exception。同样，在某些情况下，当客户端请求删除时，它会导致更新（可能是状态更改或设置软删除标志）。
应该在哪里处理这种情况entity.delete()（有意义吗？）或在称为Delete的应用程序或域服务中处理这种情况。我担心的是，只要存储库接口具有称为delete的方法，任何客户端都可以绕过服务方法并直接调用回购方法。
只是为了添加上下文，我将如何构造层是通过Java包，并使用包可见性作为一种工具来防止破坏层之间的交互。
可能对于某些域逻辑实现实体需要访问repo以更新/删除self或任何相关实体.听起来不对吗？
我的项目中有一个全局配置对象，并且我想在数据库中保留该类的 0 或 1 个实例。做这个的最好方式是什么 ？我在这里知道的一个技巧是映射一个“常量”字段，并在其上设置唯一的约束，是否还有其他这样的方法，因为这看起来有点hacky？
这是我尝试过的：-
@Entity
public class DTLdapConfig implements Serializable {
@GeneratedValue(strategy=GenerationType.TABLE)
@Id
private int id;
@Column(unique=true)
private boolean singletonGuard;
// no public setter getter for singletonGuard
// other code below
}
根据 DDD 或六边形架构记录的推荐实践 - 域模型应该与与实际使用的技术（表/列名称、联接等、JPA 注释）更相关的数据模型表示分离。这里的一个实际问题是——如何在这个模型中进行诸如乐观版本控制之类的事情？假设您有一个域服务，可以在域模型上读取-->更新-->保存。现在，JPA 实体可能有一个无法向上传递的版本列。因此，当保存调用到达存储库并且存储库本质上再次进行（模型->实体）转换和读取+更新时，它将无法判断最初读取的是实体的哪个版本。
第二个问题是对此的性能考虑，涉及这里的一些额外阅读
dns domain-driven-design jpa hexagonal-architecture onion-architecture
我要实现文档管理服务为业务流程层底层服务，如存储，分析，反病毒扫描等之间的编排要求是使层灵活，针对不同类型的文档，不同的流可以快速实施
的一个方法是将其建模为事件驱动系统，并使用 Apache Flink 等框架在事件上实现处理管道。
另一种思考方式是——工作流。将此设计为在 Apache Airflow 或 Uber Cadence 等工作流引擎上运行的工作流。
什么是更好的方法。
我有一个场景，当用户请求删除时，可能会根据某种逻辑将给定实体标记为软删除或硬删除。
从 DDD 范式解决这个问题，我看到了一些问题：- DDD 建议对所有与持久性相关的东西使用 Repository 对象，其中域层仅定义这样的存储库接口（包含存储、删除、查找等典型方法）和包含存储、删除、查找等典型方法的基础设施层实际执行。考虑到，对于我这里的问题，决定是否进行软删除的逻辑属于域层，如何才能以这样的方式包含域层中的逻辑，即任何其他删除请求的安全性在实际调用 RepoImpl 上的删除操作（实际上从底层存储中删除实体）之前，层会通过此逻辑进行引导。
即使我有一个具有类似方法的域服务void removeEntity(Entity ent)，但事实上我必须在我的存储库接口上有一个名为 的公共方法，这void remove(Entity ent)违背了目的，因为我无法强制removeEntity执行服务层的方法总是被调用，而不是remove在存储库上调用RepoImpl 需要有一个删除方法来实现实体的删除。
建议的解决方案
==============
我有一个看起来相当做作的想法，假设 Repo 接口有一个抽象实现，它提供了一个 Final public void remove(Entity ent)，抽象实现可以执行此逻辑来确定是否它是软删除或硬删除。如果它是软删除，它实际上是设置了适当标志的实体的更新，因此它调用this.store(ent)，否则它将实体包装在DeleteEvent类中
public class DeleteEvent<T>{
//parametrized for Entity
private T ent;
DeleteEvent(T ent){
this.entity = ent;
}
public T getEntity(){
return this.entity;
}
}
请注意，非公共的包访问构造函数，此类的对象只能从域层内构造，因此 RepoImpl 上的另一个删除方法是void removeFromStore(DeleteEvent evt) RepoImpl 从该密封器/持有者获取实体并实现删除过程。
虽然看起来可以工作但相当古怪/hacky，有没有更干净的方法来实现相同的效果？