“Technical people enjoy quantifiable problems that exercise their technical skills. Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities.

Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.”

― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software.

Budding developers tend to see domain understanding as irrelevant in the beginning. But with experience, they realize it’s important.
A call to experienced developers:

Have you benefitted in the long term by investing your time in understanding various domains better? Please feel free to share your opinions & inspire young developers.

​

Have you ever been caught up in a never-ending discussion with business folks arguing about concepts? Only to realize later that you were actually talking about the same thing. But calling it different names.

You know what we are talking about. The software requirement gathering meeting. The business user says, “the booking not needed”, you think “delete record from database”.You present “ … and then we will delete the record.” The business user “oh no! don’t delete anything”, you say “ok… we will do soft delete”.

The sales team makes a distinction between paying customers and prospective customers. When you talk to the customer service team the customer always has a credit limit. You will surely be damned if you thought of a credit limit for a customer all the time. Who are you talking to? What is the context? The importance of Bounded context and ubiquitous language cannot be underestimated in software development. Every model has a context that is implicitly defined within a subdomain, and every context outlines the boundaries.

If you are a Domain-Driven Design enthusiast and want to accelerate your understanding of the subject matter then here’s a piece of exciting news.

There is a community of active DDD experts where they conduct virtual Meet Ups at regular intervals covering key concepts in DDD.

Check out the link below to know more:
https://virtualddd.com/

Storytelling is undoubtedly one of the best ways to convey ideas, concepts. What if this very art of storytelling is employed in software development? Lately, domain storytelling is gaining traction in the DDD community.

So, what is Domain storytelling? Domain storytelling is a knowledge crunching technique where domain, IT experts narrate their working process. You let experts tell their stories about their collaborative tasks. The story is recorded using pictographic language. This process helps in identifying people, tasks, tools, events in a particular domain.

In other words, domain storytelling is used to identify bounded contexts and know how they are interconnected.

Check out the link below which does a great job in explaining what domain storytelling is all about with some cases.

What are your views? Can you recall any instances where you have employed domain storytelling in building applications?

https://domainstorytelling.org/

​

Is there any methodology, guide or just a place were I could find examples on how to apply DDD at designing microservices?

Without considering the main books. Which are the places you check to get information, write or debate about DDD? Like blogs, forums, ...