-1

we are tackling the domain of https://en.wikipedia.org/wiki/Factoring_(finance)[factoring][1]:

Factoring is a financial transaction and a type of debtor finance in which a business sells its accounts receivable (i.e., invoices) to a third party (called a factor) at a discount.

we are facing a major re-engineering of that central piece of domain, the "accounts receivable" part, which we currently just call Debt - it's short, there's no need for acronyms, everybody understands it.

However (not being a native speaker) it seems that the actual, correct term in that domain is "Accounts Receivable" (which we are familiar with in the accounting-domain).

Being an software engineer who rates explicit, correct naming very high, I am currently discussing with our product owner which naming to choose. I would like to not have a monstrous wording like "Accounts Receivable" or its acronym "AccRec" all over the source code. On the other that, if that's what it really is ...

Any advice appreciated!

Improve this question
4
  • 2
    if you think AccountsReceivable is a monstrously long name, you must not code in Java :P Commented Sep 2, 2019 at 8:24
  • 1
    @KevinVanDyck nothing prevents you from writing Java with single character names for everything. I'd expect that when writing software in the financial field, you'd want correctness and clarity over succinct naming. Commented Sep 2, 2019 at 9:21
  • 4
    Use the names the Ubiquitous language says you must use, not the one that P.O. likes most. If the domain experts use "Accounts Receivable" to say "Debt" then use "Accounts Receivable"; the components must reflect the U.L to establish a language everybody understands. "AccRec" is a horrible name for a class whether you follow DDD or not. Commented Sep 2, 2019 at 10:07
  • Same Ubiquitous Language applies for acronyms or abbreviations: Do they convey meaning to all stakeholders? Consider some XML output with a tag like <AR>. This may be technically used in a setter like output.setAR(String accountReceivable). But how do you pronounce it when speaking about? What does it tell you about the meaning? Instead let your code communicate and use setAccountReceivable(String accountName) where the parameter became free to specify the representation of expected argument. Commented Feb 23, 2021 at 6:46

1 Answer 1

Reset to default
7

The idea behind the Ubiquitous Language of DDD is that no translations take place between business-related terms. This means that if you need to present your design to the business side of the company (or they happen to see your source code), you don't need to explain to them why you have chosen those names for the domain concepts, because you are using the same terminology there as they are using in their daily discussions.

With that in mind, the actual correct term is how the domain experts within your company (or with the customer if you are building the software for someone else) call it. If they consistently call it "Accounts Receivable", then that is the name you should also be using. But if they find that too much of a mouth full and just refer to the same concept as "Debts" or "Invoices", then you should follow suit. If they use different names interchangeably, then there is room for negotiation.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.