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.
And 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.
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.
A 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: