ddd-repositories

    4热度

    2回答

    假设我有一些DDD服务需要一些IEnumerable<Foo>来执行一些计算。我想出了两种设计: 摘要与IFooRepository接口的数据访问,这是相当典型的 public class FooService { private readonly IFooRepository _fooRepository; public FooService(IFooRepository

    1热度

    3回答

    我知道这是一个常见问题,但我还没有找到另一个解决我的疑惑。 通常,如果项目很小,我会在表示域对象的同一个对象中使用持久性注释。这允许从数据库加载实体并使所有设置器保持私密,确保任何实例始终处于有效状态。就像: @Entity class SomeEntity { @Id @GeneratedValue(strategy = GenerationType.AUTO)

    0热度

    2回答

    我有一个应用程序服务(AppService)和一个从外部数据提供者读取数据的基础设施库(InfraRepo)。 AppService调用InfraRepo并将数据返回给客户端。 我有以下要求:我有一些过滤条件和业务逻辑。为此我创建了一个域服务(DomainService)并将其注入到InfraRepo中。一旦我从外部数据提供者(在InfraRepo中)中检索数据,我就会调用域服务,将数据传递给那里

    0热度

    1回答

    我在DDD有界上下文中使用多个聚合根。 例如 public class OrderAggregate { public int ID {get;set;} public string Order_Name {get;set;} public int Created_By_UserID {get;set;} } public class UserAggregat

    8热度

    4回答

    我已阅读并感悟到自己,实体(数据对象 - 对于JPA或序列号)在他们注射是一个坏主意。这是我目前的设计(所有适当的领域都有getter和setter方法,以及serialVersionUID我跌幅为简洁)。 这是父对象,它是实体组成图的头。这是我序列化的对象。 public class State implements Serializable { List<AbstractCar>

    1热度

    2回答

    如果我们考虑一个标准的持久性存储库,解决方案很简单。我们将IStuffRepository放入域层,并将StuffRepositoryImplementation放入基础设施层。 但是,当我们想要包装第三方API时,什么是好模式? 我们可以应用相同的模式,在域层中有一个IStuffGateway,在基础设施层中有一个StuffGatewayImplementation。 但是这种方法存在问题。当我

    2热度

    4回答

    当前的项目需要我们在NoSQL数据库(如mongoDB)中持久存在域对象。 在很多例子中(包括Eric Evans,Vaughn Vernon),域对象都被序列化并直接保存到mongoDB中。 我们希望通过在域对象中没有任何注释来避免混合域层和持久性相关的信息。 此外,我们担心未来通过更改域对象来破坏持久数据。 我们得出结论,我们需要在域对象和持久数据之间转换某种DTO。 有没有人遇到过这种情况的

    1热度

    2回答

    我所有的实体都是接口的实现。他们的大多数属性都是只读的。 我的存储库保存了一个对库项目的引用,我拥有所有的接口,所以从技术上讲,存储库可以保存聚合根不知道它是事实上的实现(我认为是+1) 。 这里的问题是:如果大多数属性是只读的,那么如何在不破坏OOP原则的情况下重新集合一个聚合根?存储库是否需要引用域项目并意识到接口的具体实现?

    2热度

    1回答

    有一些属性对域没有意义,但对于存储库来说是必不可少的,其中一个例子是分区键。 在我的存储库上有一个DTO可以扩展实体的基本实现,添加相关字段吗?

    1热度

    1回答

    我刚开始学习DDD。所以我很抱歉的问题... 所以我有Post实体。它看起来很好。但它应该有tags。 在代码中,它看起来是这样的(Ruby代码): class Post attr_reader :tags attr_reader :title attr_reader :text # ... end class Tag attr_reader