class and multiplicity

[xenoterracide]

https://contextmapper.org/docs/aggregate/

How do I have a non value/entity class. In a Domain Model in the past my model for a certain security feature was composed using the strategy pattern and the strategies were key. I also have a security model class that is ephemeral and mutable.

Also how do I do multiplicity (or whatever) e.g a list could have a 1 on oneside and a * on the other, e.g.

Class01 "1" *-- "*" Class02 : contains

[stefan-ka]

Hi @xenoterracide

Our domain models are based on the DDD patterns: entity, value object, domain event, services, etc. Would be interesting to have a concrete example where you really need any other type of object. Whats the use case behind your strategies? Can you share the model?

To you second question: You can use lists or sets in CML; with the - you indicate references

- List<ReferencedObject> objects;

[xenoterracide]

yeah, but that's not really UML. I believe you'll find that DDD gives a useful but not complete set of patterns ;) I suspect a read of the blue book would say that it's not a comprehensive list rather more of a core list. I can almost guarantee that if you ask the experts they would say that other patterns are valid as it's "solving complexity". Still, I found the answers here.

http://sculptorgenerator.org/documentation/advanced-tutorial

oh the use case, I can't share the full model, haven't actually touched that in years. Essentially we had... a display of our aggregate that changed depending on the role of the user viewing it. Some of the logic was simple check permission, but other parts were like if the users organization has X set, then show property Y to the user. Originally the logic was a massively unreadable mess of if's &&'s and ||'s. Turned out the logic was unique to the user's role, so a strategy was created that matched the role.

e.g. PublicUserStrategy, OwnerAdminUserStrategy, PayerAdminStrategy, LabAdminStrategy, or something like that. The strategies were then used to produce anemic two step view objects via an assembler service.

[stefan-ka]

@xenoterracide

Good that you found your answer ;) Was just curious whether you have an example, because in my experience people often think that they need other concepts, but they don't...

Conforming to the UML is by-the-way not one of our goals :)

[xenoterracide]

Another important bit to that, you had to pass the Organization and Lab Test Enitties to the assembler with the Strategy to make it work.

Very complex logic. The patterns you mention are not always sufficient to model a domain's business rules. They are simply the most common patterns.

[xenoterracide]

If you work on the other project it would still be good to have Class because !immutable is a violation of a value object. If you reread that definition they are by definition immutable.

[xenoterracide]

Sorry that I'm continuing, but BasicType IIRC isn't a thing... Money, is a ValueObject because it's immutable and one instance with the same value is exactly the same as another.

[stefan-ka]

Sorry, maybe I'm too stupid, but based on your comments I can no longer follow your thoughts.

"If you work on the other project" -> what other project are you talking about?

"it would still be good to have Class because !immutable is a violation of a value object" -> I cannot follow this argumentation; what has this to do with value object? Of course you should not model a value object, if your object is not immutable. A value object is immutable by its definition. I would definitely not go for a Class since this is a very technical concept of OO programming languages. This is not the level of abstraction that should be modelled in a domain model; in my opinion.

"Money, is a ValueObject because it's immutable and one instance with the same value is exactly the same as another." -> totally agree.

"BasicType IIRC isn't a thing..." -> no idea what you mean and why this is related to the sentence above. I never recommended using BasicType.

I'm always happy to help if you take your time to compose a concrete request/requirement ;) Or to answer questions of course; as long as I can understand them.

[xenoterracide]

"it would still be good to have Class because !immutable is a violation of a value object" -> I cannot follow this argumentation; what has this to do with value object? Of course, you should not model a value object, if your object is not immutable. A value object is immutable by its definition.

This is not the level of abstraction that should be modeled in a domain model; in my opinion.

The documentation show's use of !immutable, which might only be the sculptor documentation though, my reading is blending together, atm, and it's late.

"Money, is a ValueObject because it's immutable and one instance with the same value is exactly the same as another." -> totally agree.

The example's show it as a BasicType

I would definitely not go for a Class since this is a very technical concept of OO programming languages.

BasicType is worse since it's explicitly documented as corresponding to a hibernate concept. This definitely does not belong In your domain model. I'd be happy with an alternative to Class but the existing types really don't work for "not one of these others". where my actual class name represents the more important domain concept. This is a database implementation concept, which exists below the domain layer. Looks like maybe this is simply part of my sleepy blurring.

You were asking about the use case, and the use case is simply domain types that don't fit neatly into the blue books pattern list, as it's not comprehensive. Strategy and State Machine are GoF and I'm certainly not listed because they weren't deemed important enough or require further clarification.

I suppose the further request is just for some type, I'm suggesting class (business people have no idea what an Aggregate is either and it's also an OO Concept that predates DDD). However, that may belong in the sculptor repo, not sure.