Software Technical Writing Speaks Ubiquitous languages
Users have problems to solve, software engineers have solutions to build, and technical writers connect them like a bridge: the ubiquitous language recipe is the concrete of that bridge
Domain-driven design is not yet a standard
At least in the software industry, why is the domain-driven design approach not a consolidated standard?
I asked ChatGPT, which answered:
There could be several reasons why domain-driven design (DDD) approach is not yet a consolidated standard in the software industry:
Complexity: DDD is a complex approach that requires a deep understanding of the domain, and it can be challenging to implement for teams that do not have the necessary expertise.
Lack of education: There might be a lack of education or training on the subject, which can lead to misconceptions and misunderstandings about the approach.
Resistance to change: Some teams might be resistant to change and prefer to stick to the traditional software development methodologies they are familiar with.
Resource constraints: Implementing DDD requires a significant investment of time and resources, which might not be feasible for some organizations.
Lack of awareness: There might be a lack of awareness about the benefits of DDD, especially among smaller or newer software development teams.
Maturity of the industry: The software industry is still evolving, and it may take time for a relatively new approach like DDD to become widely adopted and standardized.
It’s worth noting that while DDD may not be a consolidated standard in the software industry, it is gaining popularity, and many organizations are adopting it as a best practice for developing complex software systems.
Well, let’s challenge ChatGPT by asking the opposite:
At least in the software industry, why is the domain-driven design approach a consolidated standard? That’s the answer:
While domain-driven design (DDD) may not yet be considered a consolidated standard in the software industry, it is gaining traction and becoming increasingly popular among software developers and development teams. Here are some reasons why DDD is becoming a more commonly used approach:
Focus on the domain: DDD emphasizes understanding and modeling the business domain and its complexities. This approach ensures that software solutions are tailored to the needs of the business, which can lead to more effective and efficient software systems.
Collaboration: DDD encourages collaboration between developers and domain experts, promoting a shared understanding of the business requirements and improving communication between different teams.
Flexibility: DDD offers a flexible approach to software development that can be adapted to different types of projects and requirements.
Maintainability: By focusing on the domain and using a modular architecture, DDD can result in software systems that are easier to maintain and extend over time.
Reusability: DDD emphasizes the development of reusable code modules, which can lead to more efficient development and faster time to market for new software solutions.
Quality: DDD promotes the development of high-quality software systems by emphasizing the use of best practices, patterns, and techniques.
Overall, while DDD is not yet a consolidated standard in the software industry, it is gaining popularity and becoming more widely used among development teams as a best practice for developing complex software systems.
Well, ChatGPT is coherent: DDD is not a standard.
Consequently, the way that domain-driven design provides to tame the language is not a standard in technical writing, which is a severe deficiency.
Let’s see why.
Ubiquitous language
What is ubiquitous language? Quoting Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy, by Vlad Khononov:
Using a ubiquitous language is the cornerstone practice of domain-driven design. The idea is simple and straightforward: if parties need to communicate efficiently, instead of relying on translations, they have to speak the same language.
We are in the communication domain. Quoting Khononov again:
The ubiquitous language must be precise and consistent. It should eliminate the need for assumptions and should make the business domain’s logic explicit.
Here we are! The reason why I state that technical writing should speak ubiquitous languages is that they aim to remove assumptions from the discourse.
I warmly invite you to read the Khononov excellent book to learn how to master the ubiquitous language technique. For this article, it’s time for the takeaway.
Takeaway
Getting into simple is tough: that’s well known.
Yet, how lucky are we when discovering that a path to simplicity is already there and we only need to learn it?
Sure, no recipe fits all context. Domain-driven design and its ubiquitous language may not be the perfect solution for you, but nothing prevents adapting or improving it.
The takeaway is: try it!
Stay tuned!
If you enjoyed my article and found it helpful, please consider joining Medium through my referral link: you’ll support my writing and get into a sea of knowledge. No extra costs!
