Domain-Driven Design | TutOriAL…(para [des] y entendidos) by Chris Peters

In my country, you won’t make it through school without reading how Goethe’s Faust complains, I’ve studied now Philosophy – And Jurisprudence, Medicine, – And even, alas! Theology – All through and through with ardour keen! – Here now I stand, poor fool.

Sadly, none of his efforts and studies helped the doctor to perceive whatever holds the world together in its inmost folds.

Domain-Driven DesignAnd here we are in IT: We’ve studied languages and frameworks, libraries and even – alas – the IE! All through and through with ardour keen. But how many times did we focus on whatever holds the application together in its inmost folds? Today’s topic is the business domain.

Business Logic and Software Design

Business logic is sometimes considered to be unique, and it is by definition! If the business logic of an application wouldn’t be unique, there’d be no need to write an application, as there’s already an existing solution (with the exception of when an application exists but is not available). Hence, many developers see themself as pioneers, to boldly go where no man has gone before. Romantics aside, while the business logic itself may be unique to a noteworthy degree, the techniques to implement it are not. That’s why smart process models like Rational Unified Process or Scrum along with techniques like iterative and incremental development cycles were invited. Talented software architects have elaborated approaches for software design as well; among them Eric Evans who coined the term Domain Driven Design in his book with the same title.

Developers go boldly, where no man has gone before.

I’ll give an overview on how Domain Driven Design can influence the consulting process, as well as its basic concepts for designing a domain model. Finally, we will discuss the infrastructure requirements that are needed to implement a domain with ease.

Engineering Requirements

Let’s say you are a software architect on a non-trivial application with a non-trivial domain, like the core engine of a large logistic company. Many people are joining the planning talks, among them project managers, account managers, marketing, consultants and so on. Not everyone is needed to get the job done (I won’t share my opinions on to whom this applies), but two people will play a crucial role during the process of requirements engineering: you, the architect, and the domain expert.

software architect (at least in business context) should have a very good abstract understanding on how processes work, how they are designed and optimized.

That’s true because business applications are mainly about designing efficient and beautiful digital equivalents of business processes. A domain expert should have an in-depth knowledge about a specific set of processes, namely the processes that are taking place in the logistic company and that should be reflected by the application. I found that business consultants, sales manager and marketing experts make a few good and valuable points along the way, but as long as you don’t have someone in the team who got his hands dirty in years of experience, the project will fail. For example, your domain expert should know the width of the loading ramp at the depot and if there’s enough space to install a barcode scanner.

So it’s you, specialized in digital business processes, software design and [fill in your favourite tools here], and an expert on logistics with knowledge on the company’s clients, employees and the day-to-day routine. Chances are, you’ll talk at cross-purposes. Domain Driven Design suggests some strategies that can form a powerful technical consulting service. Here’s mine:

  • Create an ubiquitos language
  • Build a glossary of keywords
  • Shift from a process oriented view to a domain centered approach.
  • Build a visual model as the foundation of your business logic.

Sounds like fun! Let’s dive into the details.

In every industry, every group of experts has its own terminology. It’s refined in every company and enriched with the companies special terms and product names. Think of IT: when people like us meet for serious geek talk, who else would understand a word? The same is true for your domain, and the first thing to do is to define a set of terms. Walk through the entire set of processes that the software should reflect and listen closely how the domain expert describes it. Any domain specific terms should be defined in a way that dictionaries do. You should be aware of words that sound familiar but are not in the given context. Some companies have never done that job before, even if it’s valuable for other areas.

Make a dedicated glossary of your ubiquitous terms, be sure that it gets approved by the client, and charge for the consulting process! A glossary may look like this:

Using Networks to Find Knowledge

As you can see, effectively using the knowledge of the business means trying to get better connections to reduce the size of the “I don’t know who to ask” space.

So how can we do this? One possibility is that we direct our questions to people in the organization that we know are very highly connected. However, one simulaiton study of search in a real organizational network has found that this might result in more steps needed to find the right person. In this simulation, a slightly more efficient search could be conducted by going to the manager who is responsible for the subject area that is being investigated or by starting the search in the right department.

Last week Ralph Ohr left me with a challenge to think about how to use experts to get the best outcomes on making decisions under conditions of uncertainty. We constantly miss disruptive changes in the operating environment and I suppose if I really knew the answer, I wouldn’t be posting it on a blog.

Sometimes predictions are genuinely impossible because of true uncertainty. The future is the future and nothing in the past can help us predict some events. Rather than making predicitons, operational flexibility is probably the best response to this type of uncertaintly.

On the other hand, sometimes the emerging disruptions are right under our noses and the problem is getting over myopia. Experts can suffer from myopia as well as the rest of us so perhaps the issue is finding the right expert with the right interpretation of what is happening. Leer más “Using Networks to Find Knowledge”