Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for false cognate aggregates within separate bounded contexts #305

Open
trevorkerby opened this issue Oct 5, 2021 · 2 comments
Open

Comments

@trevorkerby
Copy link

trevorkerby commented Oct 5, 2021

Note: Aggregate names must be unique within the whole CML model.

Error: Multiple aggregates with the name 'Artist' have been declared.

As I understand it, in Domain Driven Design, concepts that happen to share the same name as another concept is an understood occurrence and it's not necessarily in line with the philosophy of Domain Driven Design to avoid such occurrences. This could very well include aggregates. Is that not one of the reasons we use Bounded Contexts?

On page 48 of Implementing Domain Driven Design Vaughn Vernon writes:

When we consider that there are at least four Subdomains in the e-Commerce System, it’s almost certain that terms and meanings collide there. For example, the term Customer must have multiple meanings. When a user is browsing the Catalog, Customer means one thing, but when a user is placing an Order, it means something else.

In Writing Great Specifications Kamil Nicieja mentions:

False cognates aren’t necessarily mistakes. As I said before, different groups of people will use subtly different vocabularies in different parts of a large organization. You can’t force security experts to abandon their vocabulary—in which the concept of event as a logged activity is used often—just because you have another domain that uses a similar name for a different concept. [...] Trying to eradicate them isn’t a domain-driven way of dealing with false cognates.

The Context Mapper DSL is simply awesome - I appreciate being able to utilize it within my project. It is however concerning that it appears, based on the documentation and errors being reported in my IDE, to suggest that I must effectively modify my Ubiquitous Language to use it properly. Maybe I should in the case of Artist, but it seems foreseeable that I will almost certainly run into further conflicts down the road. Having to come up with potentially unnatural names that will avoid collisions with future concepts in separate bounded contexts adds a fair amount of concern in addition to the already very particular nature of Domain Driven Design.

I understand that some people believe that false cognates are dangerous, but while how good of a practice this is appears to be debated it does seem clear that Domain Driven Design does indeed support their existence. In my project they do exist, but I'd still like to use the Context Mapper DSL. Is there any way around this issue without modifying my ubiquitous language? If not currently, is there a chance that Context Mapper DSL will be able to support aggregates with the same name but in different bounded contexts in the future?

Thank you for your time!

@stefan-ka
Copy link
Member

Hi @trevorkerby

Thank you very much for reporting this one!

You are absolutely right, I can only agree with you! 👍

We have this issue (known limitation) only for technical reasons and not because we wanted to have this behavior... Basically we have to implement a proper scoping mechanism for our Xtext language, but I did not have the time so far. We also have the problem that one can simply reference domain objects within other bounded contexts without creating a relationship between the contexts.

We definitively have to fix this one and its one with high priority.

I'll keep you posted!

@trevorkerby
Copy link
Author

Wow, that's fantastic news! I kind of figured that it stemmed from a technical limitation, but from my research I've found some individuals who seem to argue against the inclusion of these false cognates. Being that I'm still learning Domain Driven Design I wanted to make sure that I presented my concern with some support and reasoning. I'm happy to hear that we agree.

Thank you for the quick and reassuring response!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants