DMN Naming convention

[Marco Iannelli]

Dear Team,

do you have any guideline/naming convention to follow while authoring DMN based decisions? 

e.g.

what would be the best way to name a BKM or Decision service?

how about decision?

thank you for your inputs

Cari saluti,

Marco

[Jozef Marko]

Hi Marco,

I do not have a proper answer on how to name BKM or Decision service. I am not sure we have a naming convention for them. I just remember a long time ago, I was told by Edson Tireli , that DMN developers have naming conventions for custom data types and they usually name it with 't' prefix. So it means custom data types are usually 'tPerson', 'tCompany', 'tEmployee' ...

--
You received this message because you are subscribed to the Google Groups "Kogito development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kogito-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/9c1c7a2b-b22a-4b9f-8b04-d7b3619b553dn%40googlegroups.com.

--

Regards, Jozef

Red Hat Partner Engineer

[Rhett S]

Can we all agree that the spaces and question-marks in the decision-node of the traffic violation DMN are maddening? :-)

"Suspension" or "dSuspension" is all that is needed. 

https://access.redhat.com/documentation/en-us/red_hat_decision_manager/7.3/html/getting_started_with_decision_services/dmn-con_decision-service-getting-started

To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/CAHZQSvqH0BUmd1gqSGzzya3q%2BxGcdeXm15neUGAhbN_2wO4pYQ%40mail.gmail.com.

[Matteo Mortari]

Hi Marco,

I believe that is more a question of Methodology than anything else, so you may evaluate and adopt the methodology which best resonates with your business context etc

For example,

Bruce Silver in his book (link)

Highlights the semantic adherence of the Name (noun) to a potential entry in a Business Glossary

Alan Fish in his book (link)

that is the prequel to what came to be DMN, suggest using short noun phrases

James Taylor and Jan Purchase in their book (link)

have a very extensive set of field-tested recommendations, ranging from "Decisions should be named after their outcome", usage of nouns, plurals, anti-patterns etc.

These are just short snippets, I don't want to give away spoilers from these precious books!

I own and have read all 3 of them above, and I would STRONGLY recommend those 3 books anytime for anyone looking to strengthen their DMN and Decision Management practices, beyond the "mechanical DMN aspects". 

By the way: the convention to name itemDefinition starting with a "t" as in "tBorrower" is mainly attributable to Bruce Silver's Method and Style, I would not say is necessarily "the" best practice among all DMN practitioners. Personally I liked it and tend to adopt it when modeling with DMN myself.

Hope these are interesting insights to you and the group ;)

MM

--

You received this message because you are subscribed to the Google Groups "Kogito development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kogito-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/9c1c7a2b-b22a-4b9f-8b04-d7b3619b553dn%40googlegroups.com.

--

Matteo Mortari

youtube.com/@MatteoMortari

linkedin.com/in/matteomortari

[Marco Iannelli]

Hi Matteo, 

especially with the reference of Alan Fish (knowledge automation) I was wondering if you ever implemented any of the patterns mentioned in the book e.g. "Category with reasons"; in the book it says to have multiple knowledge nodes, but in fact how to orchestrate the multiple "knowledge routing rule" directly in dmn? would not a single decision table be enough for such pattern?

thanks for your feedback

[Matteo Mortari]

Ciao Marco,

the book "Knowledge Automation" by A. Fish is a prequel to the DMN standard: in the book you will not find anything about FEEL, nor decision tables, nor boxed expressions.

Further, the book introduces as a premise that the actual logic must be extenalized with the knowledge nodes (represented with shadow and not yet with clipped corners) so that's not what DMN eventually evolved into, since you can clearly express declarative logic also as part of Decision nodes.

So I would concur with you, the patterns in that book beyond the abstract guidelines which are helpful, need some adaptations; representing those logics with a Decision Table rule (each) could be very applicable, you might consider a hitpolicy of Collect (without aggregation) if that also makes sense.

The category could be a simple FEEL:string that has a semantic meaning, defined in an ItemDefinition.

As for the "descriptive reason" I would suggest if it's only for documentation purposes, this could be used in Annotation column of the Decision Table; if instead is to be used as part of the decision logic it needs a compound (multiple) output column but I would caution on its valorization as using "freetext" in subsequent logic might become very tricky.

Hope this helps!

MM

To view this discussion on the web visit https://groups.google.com/d/msgid/kogito-development/7dfb0abb-7c32-4090-a905-550e98e96ad5n%40googlegroups.com.