domain-driven-design

System consuming WCF services from another system, when underlying databases have relationships

旧时模样 提交于 2019-12-12 22:03:58
问题 This is an issue that I have struggled with in a number of systems but this one is a good example. It is to do with when one system consumes WCF services from another system, and each system has their own database, but there are relationships between the two databases. We have a central database that holds a record of all documents in the company. This database includes Document and Folder tables and it mimicks a windows file structure. NHibernate takes care of data access, a domain layer

CQRS - Event replay for read side

a 夏天 提交于 2019-12-12 18:28:12
问题 I have read several blogs on CQRS and all of them explain that at write-side events are persisted on event store and upon a request, events are retrieved and replayed on aggregate. My question is why doesn't event replay on an aggregate is required at read side? 回答1: Because your read side doesn't use aggregates. Read side is implemented as projections which calculate the current state from the stream of events emited by aggregates and persist the current state in some pesistent store or in

OOP App Architecture: Which layer does a lazy loader sit in?

无人久伴 提交于 2019-12-12 18:23:34
问题 I am planning the implementation of an Inheritance Mapper pattern for an application component http://martinfowler.com/eaaCatalog/inheritanceMappers.html One feature it needs to have is for a domain object to reference a large list of aggreageted items (10,000 other domain objects) So I need some kind of lazy loading collection to be passed out of the aggregate root domain object to other domain objects. To keep my (php) model scripts organised i am storing them in two folders: MyComponent\

Domain driven design and aggregate references

别来无恙 提交于 2019-12-12 15:26:59
问题 I am designing the domain model, but there is something that doesn't seem to be ok. I start with a main aggregate. It has references to other aggregates and those other aggregates reference more aggregates too. I can travel the hole domain model starting from the main aggregate. The problem I see is that I will be holding all instances of aggregates in memory. Is that a good design? I can solve the memory problem with lazy loading but I think that I have a deeper problem. I have another

Is CQRS correct for my domain?

一世执手 提交于 2019-12-12 14:50:02
问题 I am modelling an archive which is part of an video demand system. Think of the archive like windows explorer where multiple users can create folders, upload videos, restructure folders etc. There are business rules (permissions) which determine if the user is allowed to do the task (i.e. rename folder, move folders, view folders etc). I have modeled each folder as an aggregate root and moving one folder to another folder appears to affect two aggregate roots. From what I understand is I

Solve apparent need for outside reference to entity inside aggregate (DDD)

自作多情 提交于 2019-12-12 13:51:37
问题 I'm trying to follow DDD principles to create a model for determining whether or not an Identity has access to an Action belonging to a Resource. A Resource (e.g. a webservice) is something that holds a number of Actions (e.g. methods), which can be accessed or not. An Identity is something that wants to access one or more Actions on a Resource. For example, someone uses an api-key in a call to a webservice method, and it must be determined whether or not access is allowed. As I currently see

How to handle UseCase Interactor constructors that have too many dependency parameters in DDD w/ Clean Architecture?

微笑、不失礼 提交于 2019-12-12 13:18:54
问题 Using DDD w/ Clean Architecture, I'm instantiating all of my dependencies (e.g. Repositories and Services) first and injecting them into my UseCases. What I've noticed over time is that my list of dependencies for each UseCase has grown quite large over time. For example, my UseCase uses 3 Aggregate Roots so I have 3 repositories. Not so bad. But, as I add more features, I find myself adding Domain Services or more Repositories and having to inject them into the UseCase Constructor as well.

DDD Database first . How to handle aggregates

为君一笑 提交于 2019-12-12 11:42:36
问题 I'm trying to learn the concept of DDD. I have made a project which i use the database first approach. In the infrastructure i have added an edmx file witch i have chosen to auto generate the entites. Now in the "Domain" I'm trying to create aggregates. But here i got some problems. I´m trying to create a aggregate named "User" but User already exists in the entites that the ef autogenerated. Should i rename the aggregate "User" to something else and when getting data from the db map it from

using Natural key as the ID of DomainObject or GUID + auto-increment Domain Driven Design

不羁岁月 提交于 2019-12-12 11:04:05
问题 I've been reading a lot of articles about DDD and noticed that most are using GUID as their ID when persisting to a database. They say that GUID scales well and auto incrementing ID's are a big no-no when it comes to scalability. Im confused now whether to use GUID or auto-increment . Basically the Domain is about membership system (binary tree). (tracking of register members) The first requirement is that we should have something that uniquely identifies them in the system (we call it

DDD: Should a Dto Assembler be a part of Domain Layer?

倖福魔咒の 提交于 2019-12-12 10:55:55
问题 Thanks in advance. I have some Aggregates in the Domain Layer library. Also, some DTO s in a separate library, which is shared between Server and Client side. An Aggregate of an entity is more informative than its DTO . So, in order to convert from DTO to Aggregate , a repository should be accessed by a Dto Assembler . Interfaces of repositories are in Domain Layer . That's why i come to conclusion that DtoAssembler should be a part of DomainLayer . Is this right? 回答1: No, this would be plain