5

I am going to assume that we don't have to debate the need for two systems (orders and accounts) and you have a real need for them to be so. It's a good analogy to consider each domain to be a separate microservice, that are running on different machines and ports, and are scaled differently. Then the requirement becomes clearer. It is a bad idea to try to ...


3

Which layer Repositories belong: the Domain Layer, Persistence Layer or something in the middle? If you believe in dependency inversion*, then repositories are contracts defined by the application layer and implemented by the persistence layer. The contract itself has an implicit dependency on the domain model (via the appearance of the domain entities in ...


2

I basically need a factory function inside my DomainModel that accepts a PersistanceModel and do not trigger any events, is this smelly good? In practice, that's probably going to work out fine. Here's the key point I know some of you will say that this model can be refactored etc, but since I'm writing software for my organization and we use old ...


2

While it does seem like you have many structs floating around, these are necessary for a clear separation of concerns. You could skimp on some and directly pass around dictionaries and lists, but you would be losing some vital domain context. The number of structs is only going to increase as your application grows over time and becomes complex. But that's ...


2

Repositories and their placement in the code structure is a matter of intense debate in DDD circles. It is also a matter of preference, and often a decision taken based on the specific abilities of your framework and ORM. The issue is also muddied when you consider other design philosophies like Clean Architecture, which advocate using an abstract ...


2

Pagination is not a domain concern. The domain layer typically does not care to know the number of records fetched from a persistence store. It is a performance concern, specifically on the database side. And the only domain elements that deal with the database are repositories. So the way I see it, you need a mechanism to send it from the API request (or ...


2

Paging is an implementation detail. DDD concerns itself mostly with architectural design; it doesn't have much to say about how you handle page breaks, since handling concerns like paper size or screen length is not part of the business domain, although it can be a part of the design process. Where should you put your paging? Where it is most convenient ...


1

So, if you disregard all the "aggregate design rules" talk you can find on the net, and focus on how aggregates are described in the book, they are meant to be these bundles of objects that form some sort of a graph, with an explicit design boundary, and one object selected as the root. The root acts as an interface (facade) to the aggregate, it encapsulates ...


1

I will only comment on the design and the code from the perspective of DDD. Specifically, using the free DDD Reference by Eric Evans, pp. 9, 10 and 17 (layered architecture and repositories). According to Domain-Driven Design, domain model layer should not depend on any layer, right? I think you incorrectly interpreting a statement like this: Isolate ...


1

public void Deposit(int amount) { // ... // repoTrans.AddTransaction(transaction); } This is the part of your code that is a bit weird, in terms of Domain Driven Design. The domain model is usually composed of pure in-memory representations of your domain; they own their own data structures. So you either send them information so that they may ...


1

It is a good practice to introduce an intermediate "Application Service" layer between your controller (here, your Console UI) and the Domain Layer. The App Service will be responsible for invoking the (injected) infrastructure services, calling the domain layer and also persisting/loading necessary data. The Controller's responsibility is only to gather ...


1

Having a struct containing the input parameters for each method is going to mean a lot of typing. I would simply pass the user around and not have the extra types. The code is shorter and does the same thing, you just shift the time.Now() down a level I think it's good general advice not to create seperate types for this kind of object-with-meta-data thing ...


1

tbh I'm still not 100% sure what you are asking. But I'll give you a general answer on the topic of exposing APIs for use when you have a "massive domain" by which I take to mean, you have lots of microservices for various parts of your business. "API Gateway" is a generic term that has no "official" meaning. You don't need an "API Gateway" You can add ...


1

The UniversityOfInterest aggregate must contain the business rules for determining ResidencyType. Given that determining ResidencyType requires information from two different aggregates (Student and University), this responsibility doesn't really fit into UniversityOfInterest and would be better modeled in a domain service. UniversityOfInterest should be ...


1

Start by creating a folder within the solution by separating projects by features or departments and one folder for cross-cutting or shared projects as you prefer. After that, within each folder you created for each feature you can add other subfolders to Data Access, Domain Model, Application and UI. This already will be a good start to application of DDD....


Only top voted, non community-wiki answers of a minimum length are eligible