We are working on a ubiquitous language; however, there are different terms used for marketing purpose and one used for product team and engineering team. The marketing team's term is more for PR purposes. Wondering in this case, is it OK that we have one terms that is specifically for marketing team and one for product and engineering?

  • 1
    I think this is actually an interesting question. I see one close-vote. Don't be so quick to judge this question. This is all a matter of perspective - who are you building the system for? Commented Sep 5, 2023 at 17:00
  • The system is built for consumers.
    – Danny
    Commented Sep 5, 2023 at 17:14
  • Ever heard of something called a Bounded Context? :) Commented Sep 5, 2023 at 20:59
  • From the question it’s not clear if (part of) the software is actually used by the marketing department, or that they are marketing a product built by your org.
    – Rik D
    Commented Sep 5, 2023 at 21:27
  • they are marketing the product built by eng and product
    – Danny
    Commented Sep 6, 2023 at 2:53

6 Answers 6


Sure, DDD dogma might say this does fit into the idea of the ubiquitous language. But the real question you need to answer for yourself is "how much does it really matter?" and what's the cost/benefit relationship of working with two different terms in your specific situation?. Hence, ask yourself:

  • Is there a high risk of confusing people? Is the "marketing team's term" a term which is unique and can easily be mapped to the terminology of the other teams, and vice versa? If yes, it should not be much of a problem. But if the marketing team's term is also used in the engineering world, but with a different meaning (or vice versa), that should be a warning sign.

  • How much is the marketing team involved into requirements analysis and design of the product? If they participate here, the need for having unique terms is much greater than in case they do not. If it is the latter, just let them use their own terms in their sandbox and keep smiling. If it is the former, teach the marketing team the tech people's terms, insist on usibg only these terms in internal discussions and let it be the marketing team's problem if they want to use different terms for PR.

  • Maybe there is a business reason why the marketing team prefers a fancy and intentionally vague term, but for technical purposes, that term might be too vague and ambigous? Maybe someone expects to sell the product more often with these "not-so-technical" names and terms. That would be a reason to stay away from making terminology equal.

For example, from a software engineering perspective it is somewhat debatable to call a software product like a specific programming error. From a marketing perspective, Stack Overflow has itself proven to become a very successfull name, though its original meaning from the time before 2008 was definitely not "Q&A website for programmers". Still I would not try to force software engineers at Stackexchange to use the term "stack overflow" for stackoverflow.com exclusively just for the purpose of making the language ubiquitous.

In the end, it is trade-off, and you have to discuss it in your organization how important it is for them to use one term, or two.


If you have one term used by the marketing team for marketing purposes and another term used by the product and engineering teams, then you do not have a ubiquitous language. In Domain-Driven Design, "ubiquitous language" is a vocabulary that is shared by not only the product development team but also across all the stakeholders. As soon as you have two groups using different terms for the same common concept, you no longer have uibquitous language.

The reason that ubiquitous language is so important is that it reduces ambiguity. Written and spoken languages already tend to have a good deal of ambiguity, but it is difficult to deal with ambiguity in software. Using a language that maps not only into the software, but in conversations with stakeholders about the software, is beneficial.

If you're working on a greenfield system, take the time to establish your ubiquitous language and use it throughout the system and conversations about the system. If you're working in a brownfield system, it could be beneficial to invest the time to refactor existing terms to your ubiquitous language and start using it.

  • In our case, it is often that marketing team is evolving until the last minute. We cannot really have a final term until the product launch. How we handle that scenario?
    – Danny
    Commented Sep 6, 2023 at 2:52
  • 3
    @Danny: when marketing people invent new terms and slogans until the last minute, it is obvious they are not using these terms throughout the analysis and development of the product, so it does not really matter for the development. And when their fancy terms help to increase the number of sales, it can be perfectly justified to let them use them - it does not help your organization when your team follows the DDD ideas dogmatically, but does not reach the expected revenue,
    – Doc Brown
    Commented Sep 6, 2023 at 5:04
  • 1
    @Danny Why are they doing this? Perhaps you should look to other stakeholders - the customers buying your product and the people using it - to see what terms they use. It is possible that there is no universally accepted term, but that doesn't mean that you can't pick one and use it as the primary term everywhere and identify synonyms for it. If you don't have the language, analysis, design, and validation becomes that much harder, so it's worth developing the languge.
    – Thomas Owens
    Commented Sep 6, 2023 at 11:01
  • Let's start with how not to handle that scenario. Do not attempt to rename everything in code at or after product launch when marketing has cemented the term. Not only is it a useless time sink but there is a high probability you will break something. Let's reason back from there. Either terms need to be set before engineering builds, or the org needs to accept non-ubiquitous language. Commented Sep 6, 2023 at 13:41
  • @nonethewiser If renaming something would cause your system to break, that means you have insufficient (automated) test coverage. Although it's better to get the name right from the start, it's not always possible, especially as the system evolves. There are several refactoring patterns about renaming, such as Rename Field and Rename Variable. Agile Data also describes approaches for database refactoring.
    – Thomas Owens
    Commented Sep 6, 2023 at 15:01

there are different terms used for marketing purpose and one used for product team and engineering team.

Some may say that makes a ubiquitous language impossible. I say, not so fast.

Group A Group B
Term 1 X ?
Term 2 ? X

You’ve told me about the Xs. You haven’t told me about the ?s. When terms compete the winner is the one best known.

The marketing team's term is more for PR purposes.

This makes me suspect marketing might know the other term. They just don’t consider it wise to use in front of customers. For example:

Engineering Marketing
Foo Surcharge X X
Foo Discount ? X

In this situation the Engineering team thinks Foo is a simple situation where you add a fee to a base charge that is used in many situations. However marketing absolutely wants people with Foo to feel they’re getting a good deal. And they are. Since they could be paying more for lots of reasons.

Which makes sense, unless you just want a simple way to calculate what to charge.

So you start to think, ok this is just a presentation problem. We just have to be careful what we show the customers. Marketing is just blowing their smoke.

That is until a court order drags a member of the engineering team up on the stand to read an email about the “Foo Discount” really being a surcharge.

These disconnects can cost time, money, freedom, and lives. Find a way to get everyone speaking the same language. Even if you have to let a flipped coin decide which term to use. Just make sure to tell everyone what the coin said.

Flipped coins have the ultimate authority over arbitrary decisions, provided the legal department doesn’t care.

  • I'd assume the question is about differences that don't have legal consequences - an engineering team developing a feature and calling it "encabulated widget counter", and marketing saying "that's technobabble, we'll just call it HyperCount". So more like project codenames than deceptive marketing - if it's the latter, your internal names will leak in source code, headers, random error messages, etc., and you will get burned. Commented Sep 6, 2023 at 11:29
  • 1
    @MaciejStachowski the legal example is meant to show how impossible the leak can be to prevent. Commented Sep 6, 2023 at 11:55

Wondering in this case, is it OK that we have one terms that is specifically for marketing team and one for product and engineering?

It is both, it is ok and it isn't ok. It depends. When the organisation the language is developed for it is a proprietary products organisation it is the way to go since marketing is the company's outside image that among others has to protect the intelectual property of the products, when the organisation the language is developed for is an open source organisation then it is confusing.

Taking the argument further for proprietary products it becomes strange considering Conway's law

organizations design systems that mirror their own communication structure

to use different languages between the teams, those interested in intelectual property could understand it just by changing the terminology the marketing team uses, they just need time to figure it out.

To sum it up, it is both ok and not ok with the mention that it is ok though might be useless.


Marketing department is a player to be reckoned with, even if not involved in design and modelling. They will advertise things under different names and soon enough your end users, support team, etc. will start talking with these terms too.

Align the languages as much as possible, and when not, make sure there is a solid user onboarding (in-software cues, training, documentation etc.) that will transition them from the catchy buzzwords they read in the commercial leaflet or website to the real language of your system.


DDD has the concept of "Bounded Contexts" to solve this issue.

The Marketing BC might have Marketing.Customer while the product team has Product.Customer the ubiquitous language only applies within a bounded context.

Now. You might well be thinking. "that is a plain contradiction. Should I have one language which everyone agrees on or several with confusing terms?!!"

And you would be 100% right. DDD and the like are made up to sell consulting services. When a customer complains that they don't work, they add some wiggle room or a work around. "Oh we are still doing scrum! just without the standups", "on wednesdays we do KANBAN" etc

You can't expect these things to solve all your problems. Get Marketing to change to the same terms as everyone else, or given them a special MarketingCustomer object and make sure you make the distinction between that and NormalCustomer. But don't whatever you do just call the two different things both Customer

  • I think you may have misunderstood the question - as I read it the OP is talking about terms the marketing team use when addressing the public to sell the product - not the terms they use within their team to talk about marketing.
    – bdsl
    Commented Sep 5, 2023 at 18:48
  • ..no i think my interpretation is correct, it has the DDD flag
    – Ewan
    Commented Sep 5, 2023 at 19:22
  • 2
    The software that deals with a product in the context of a catalog has different behavior than the software for same product in the context of a warehouse. That’s what DDD solves with Bounded Contexts. I don’t think in this case there’s any software built for the marketing department at all; it’s just that they use a different term than the domain experts in the actual context do.
    – Rik D
    Commented Sep 5, 2023 at 20:04
  • I mean there are two other answers here that interpret it the same way. I don't see why you can't have software for a marketing dept?
    – Ewan
    Commented Sep 5, 2023 at 20:36
  • Since one of the other two answers here is mine, I can say I don't interpret the question the same way you do. Although it's a valid point about the term from the ubiquitous language applying within a bounded context, it seems like two teams have two different terms for the same concept and not the same concept seen through two lenses.
    – Thomas Owens
    Commented Sep 5, 2023 at 22:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.