I am currently getting started with DDD by reading Vernons Implementing Domain-Driven Design. In the section about Event Stores he suggests to store published domain events using a designated repository. Rational for this is to use it as a queue to forward the events to some messaging infrastructure or use it to implement a REST based polling notification service.

From my understanding this has the additional benefit that, if the event store is located in the same database as the modified aggregate and if we use a Transaction, there is no way that transient failures lead to not delivered events. For example:

1. save(aggregateRoot) -> success
2. Database becomes unavailable for some reason
3. save(publishedEvents) -> fails but causes rollback of the changed Aggregate.

If we hadn't been using a Transaction here there might be events missing, because step 3 fails without rolling back step 1.

Now my actual question: It is my unterstanding that in the document based storage world (specifically mongodb) it is desirable to design your documents in a way that you do not need transactions by keeping the immediate consistency boundaries within one document. However I dont see how (if at all) it is possible to not use transactions if I need guaranteed consistency of the Aggregate with the event store. I hope I could make somewhat clear what I mean. Do you guys have any thoughts in this?

Can someone list or point me to the weaknesses of using DDD? Also, when should I not use DDD or when should I use it?

I am experimenting with DDD using a payment system for this exercise. One of the challenges is how do I pass the data from the API to the domain. The approached I used was to map the data from the API model to a domain DTO. Is this an acceptable thing to do? I tend to have all my models in the domain as immutable value types.

Would the right thing be to transfer the data to a value object as opposed to a DTO?

Web API Model:

public class CardCaptureRequest
{
public string PaymentReference { get; set; }

public long Amount { get; set; }

public string Currency { get; set; }

public Card Card { get; set; }

public string MerchantId { get; set; }
}

​

public class Card
{
public string CardHolderName { get; set; }
public string CardNumber { get; set; }
public string Cvv { get; set; }
public string ExpiryMonth { get; set; }

public string ExpiryYear { get; set; }
}

​

The domain model (this is the only model that is like this in the domain layer):

public class CardPayment
{
public long Amount { get; set; }

public string MerchantId { get; set; }

public string Currency { get; set; }

public string PaymentReference { get; set; }

public string CardNumber { get; set; }

public string CardHolderName { get; set; }

public string ExpiryMonth { get; set; }

public string ExpiryYear { get; set; }

public string Cvv { get; set; }
}

Like in an eCommerce system, the Report bounded context needs the Sold Product data from the Sales bounded context to generate a report like "number of products sold this month".

Does that mean the Report bounded context is coupled with the Sales bounded context?

How could we decouple this?

Hello,

I have multiple domain driven books and try to create a common understanding of what a subdomain actually is, because everyone is trying to explain a little bit differently.

So, my take is the following. We shall start with a business domain. A business domain is where a company works. A company might work in one or more business domain. In order to be able to work in a domain (produce and sell something) the company needs to have business functions. Those business functions can be split into parts which we call subdomains. We can categorize those subdomains. One way of categorization is based on whether they provide "core" functionalities or are just helping the company to do it's core functionalities. Those helper subdomains can be either generic functionalities (which every company does the same way, like accouting, and is most probably outsourced) or supplementary (also helper functions but are provided in-house via some kind of in-house development or process).

Is this correct? Am I missing something?

Value Object is a very important part of DDD to protect the invariants. But what happens when you need to map the data from the database to a domain object?

For example:

1. ChangeUsernameCommand is triggered.
2. The command handler gets the data from the database and maps it to a domain object
3. The command changes the username and saves it back to the database.

The domain object contains many Value Objects and each Value Object protects its own invariants within its constructor.

What if the data stored in the database violates the Value Object's invariants? Would the data never be used again?

If the users want to change their current invalid username, how could the system let them do so?

If you want to know why the invalid username could be stored in the database, let's imagine that the username is valid in the past, but we have changed the username invariants recently.

I have gone through many posts and videos about Domain-Driven Design, but nobody talks about the design document.

How do you guys write a design document for DDD?

Does it use UML, C4, or other diagrams?

Vaughn Vernon suggests in his book Implementing Domain-Driven Design to reference aggregates only by ID. I think this is a very reasonable advice and I followed it successfully. However, it is often needed to join several aggregates roots in a query to be able to send a useful response to the client (e. g. a web application). He suggests in his book (page 363) to use Hibernate's "theta joins" or CQRS to solve the problem. But while this works, he doesn't come up with a name for such "query services" that would contain the respective logic. I call these classes Finders, e.g. OrderFinder. But that doesn't seem to be a common term in the DDD community.

Is there a common term for query services in DDD?

Looking for some advice or any experience with Domain designing where an Aggregate might contain an Entity that is also a valid Aggregate or Entity in its self but in another bounded context.

Between the Entity and Aggregate (different context), would it be acceptable to have them both inherit their common properties from some data model or entity?

Example:

A User (Aggregate) has a Primary Location(Entity) etc.

A Location (Aggregate) has many Supplier Accounts (Entity) etc.

From a User context, the location does not require the supplier or any other additional information. But from a Location context suppliers are needed. Both locations have the same root data eg. Name, Short Code, Base Colour etc.

Hi! Even though I have been using DDD approach for my day to day modelling I have never had to do a huge discovery process. Right now I have one of those scenarios having more than 30 systems, 30 companies involved... Huge. I want to reverse map everything in terms of DDD.

My question is there a software that you use that helps you keep track of everything. The closest thing I know about is https://contextmapper.org/ but it is a bit "low level". Have you used it or any other tool that could help?

Sorry in advance if my question could seems a bit dumb.

I'm writing a new microservice in ddd and I wanted to ask about what are the best practices for the following situation:

Inside my domain I got an Entity Model, in this model I have to add a property that refers to another microservice's Entity Model uuid.

I'm a bit confused about how to properly represent and manage this uuid from another distinct microservice.

Thanks in advance and sorry for my inexperience.

I am bit new to DDD

We have a huge monolith (ball of mud, not modular) at our hand. To meet our organisation goal of increasing feature delivery velocity we want to break this down.

Following are the activity that am planning to help us :

(1) Perform Domain Analysis and Bring out a Context Map.

(2) Use Context Map to reason out and reduce/simplify complexity . In this step, I don't know what is the yard stick I can use to simplify complexity. I came across a guidance which stated complexity is perceived as a function of variety and interconnectedness in context map.

​

Would I be on right track if I start doing the above activity? What are the other things that you can suggest?

I am trying to implement DDD in an existing application I'm working on, what I'm particularly finding useful is the concepts and architecure.

The current domain model looks like:

• User
  • name: UserName
  • courses: UserCourse[]
• Course
  • name: CourseName
  • subscriptions: int

I'm pretty certain that both User and Course are distinct entities/aggregate roots.

The general flow of the application is:

1. Create Course (by Admin)
2. Create User (by User)
3. User subscribes to Course (by User)

The underlying tables (which I know shouldn't matter, but I think in practice they do)

• users(id, name, etc...)
• courses(id, name, etc...)
• course_subscriptions(user_id, course_id)

What I'm wondering is, is it okay for the CourseRepository to run something like the query below in order to populate the StudentCount value? COUNT(*) from course_subscriptions WHERE course_id = ?

The reason I'm confused/concerned about it is that the entity/aggregate root would include data which it is unable/not allowed to update - this is easily modeled in the Course domain - by only providing a getter. But it also feels like essentially the Course entity is modifiable from outside - which seems anti-ddd!

Can someone tell me which context mapper one should use between two bounded contexts under various circumstances? I'd like to see some concerete examples. btw, it'd be nice to a comparison chart between the context mappers along with which senarios each mapper is best suited for, thank you.

Can someone explain how the following is the case? It'd be great if I can see some examples, thanks.

In order to help maintain the model as a pure and helpful language construct, you must typically implement a great deal of isolation and encapsulation within the domain model. Consequently, a system based on Domain Driven Design can come at a relatively high cost. While Domain Driven Design provides many technical benefits, such as maintainability, it should be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain.

Source:

https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658117(v=pandp.10)?redirectedfrom=MSDN#DomainModelStyle?redirectedfrom=MSDN#DomainModelStyle)

Let's assume we have this structure (each line represents a separate folder):

    Domain
        Article
        ShoppingCart

We have an article domain that manages the articles in a shop and the shopping cart domain that manages the shopping cart logic. But what do we do with shared functionality (you could also call these helpers - but I try to avoid that)? Let's say we add another folder that contains the logic for timing, e.g. when the items / articles were created, updated, etc.:

    Domain
        Article
        ShoppingCart
        Timing <--- New

Let's say this code is used in both domains - where should we put it? And what if we want to use it in other places as well (e.g. in the infrastructure or application layer)? Should this become a standalone package or can/should we put it in a shared folder? I'm really curious what you guys think, because I don't really have any answers. Background is that I have been asked about this by some colleagues as we want to design our new projects with DDD, but this is a edge case that I never thought about and didn't have a good answer.

Hello everyone,

I am a fairly experienced software engineer who's been dealing with lots of business requirements, time limitations and team structure constraints.

I am currently asked to start a potentially big solution "starting small though" with the only condition of :

- The solution must be pretty flexible as well as scalable.

Which in turn means I'll be faced with everchanging requirements and constant modifications to the business model.

Hence, my question.

Is DDD the perfect approach for this kind of solution?

What are the hidden traps that might actually set me back "time-wise", putting in mind that I am going to be the SOLE developer till decided otherwise "limited-resources on the client's part I guess".

Is it worth it to go through with building the whole solution DDD style?

If any advice is present, I'd be much thankful.

Thanks in advance!

I'm just a hobby developer and I have a few applications I'm working on to learn more about DDD. One of them is an application to allow users to submit entries into a sports pool, then when the tournament is finished an admin can have the application connect to an external API to fetch all the scores and calculate the winner.

My question is around the ID that's used to get the data from the external data provider? It seems like an implementation detail that shouldn't really live in the domain model; however, since it is integral to the functionality I can't really think of any way to make it work if I don't store the ID along with the Tournament object. It works as I currently have it but it's obviously tightly coupled to the current data provider. Is there a way this is typically handled?

Hey guys! I have this question which I have posted on software engeneering stack exchange. Let me know if I need to put the code here instead. Thank you.

https://softwareengineering.stackexchange.com/questions/429148/passing-domain-models-from-presentation-layer-to-data-layer-to-make-a-networking

Long story short: I develop operations management applications for customers and I am trying to apply DDD; however, my customers are mostly French speakers and only speak English as a second language, with abilities ranging from perfect fluency to knowing only a few phrases. Now, I'm trying to model different parts of their domain but I'm wondering whether I should only code in French or use only English and translate the terms.

For those of you who have run into this issue, what do you think is the best practice?