Domain Driven Design Chapter 1 Summary

Part I: Putting the Domain Model to Work

• An eighteenth-century Chinese map of the world shows China as the central and largest location, and is a reflection of their society at that time, which had intentionally turned inward.
• "Maps are models, and every model represents some aspect of reality or an idea that is of interest."
• "A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail."
• Software relates to some activity or interest of the user, which is the domain of the software.
• Software domains usually have little to do with computers, though there are exceptions:
• The domain of a source-code control system is software development itself.
• A model is a rigorously organized and selective abstraction of domain knowledge
• While a model can be represented by the following, it is not one of the following:
• A diagram
• Carefully written code
• An English sentence
• "Domain modeling is not a matter of making as "realistic" a model as possible. [...] Nor is it just the construction of a software mechanism that gives the necessary results. It is more like moviemaking, loosely representing reality to a particular purpose. Even a documentary film does not show unedited real life. Just as a moviemaker selects aspects of experience and presents them in an idiosyncratic way to tell a story or make a point, a domain modeler chooses a particular model for its utility."
• The Utility of a Model in Domain-Driven Design
• Three basic choices determine the choice of a model
• The model and the heart of the design shape each other
• Intimate link between model and implementation makes the model relevant
• It also helps during maintenance and continuing development, because the code can be interpreted based on understanding the model
• The model is the backbone of a language used by all team members
• Binding of model and implementation means developers can talk about the program in this language
• The can communicate with domain experts without translation
• The model is distilled knowledge
• The model is the team's agreed-upon way of structuring domain knowledge and distinguishing the elements of most interest.
• The Heart of Software
• "The heart of software is its ability to solve domain-related problems for its user. All other features, vital though they may be, support this basic purpose."
• "Yet these are not the priorities on most software projects. [...] 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."

Chapter 1: Crunching Knowledge

• "A few years ago, I set out to design a specialized software tool for printed-circuit board (PCB) design. One catch: I didn't know anything about electronic hardware. I had access to some PCB designers, of course, but they typically got my head spinning in three minutes. How was I going to understand enough to write this software? I certainly wasn't going to become an electrical engineer before the delivery deadline!"
• Tried having the PCB designers tell exactly what the software should do. Bad idea.
• Their software ideas usually involved reading in an ASCII file, sorting it, writing it back out with some annotation, and producing a report.
• Through various example dialogs between the developer and the PCB experts, the author shows the process of building up a domain model and gaining a clearer understanding in coordination with the experts.
• It starts very basic, showing the relationship between nets (a wire conductor that can connect any number of components) and chips.
• Ideas of how signal work gets added in.
• Chips are replaced with component instances, and the ideas of pin and topology are added.
• "To focus our exploration, we limited ourselves, for a while, to studying one particular feature. A "probe simulation" would trace the propagation of a signal to detect likely sites of certain kinds of problems in the design."
• "So, now, where does the Topology come into it? [...] That's not used for the probe simulation. [...] Then I'm going to drop it out for now, OK? We can bring it back when we get to those features."
• "And so it went (with much more stumbling than is shown here). Brainstorming and refining; questioning and explaining. The model developed along with my understanding of the domain and their understanding of how the model would play into the solution."
• "After a couple more part-time days of this, I felt I understood enough to attempt some code. I wrote a very simple prototype, driven by an automated test framework. I avoided all infrastructure. There was no persistence, and no user interface (UI). This allowed me to concentrate on the behavior. I was able to demonstrate a simple probe simulation in just a few more days. Although it used dummy data and wrote raw text to the console, it was nonetheless doing the actual computation of path lengths using Java objects. Those Java objects reflected a model shared by the domain experts and myself."
• "The correctness of this prototype made clearer to the domain experts what the model meant and how it related to the functioning software. From that point, our model discussions became more interactive, as they could see how I incorporated my newly acquired knowledge into the model and then into the software. And they had concrete feedback from the prototype to evaluate their own thoughts."
• Ingredients of Effective Modeling
• Binding the model and the implementation.
• That crude prototype forged the essential link, and it was maintained through all subsequent iterations.
• Cultivating a language based on the model.
• At first, the engineers had to explain elementary PCB issues to me, and I had to explain what a class diagram meant. But as the project proceeded, any of us could take terms straight out of the model, organize them into sentences consistent with the structure of the model, and be unambiguously understood without translation.
• Developing a knowledge-rich model.
• The objects had behavior and enforced rules. The model wasn't just a data schema; it was integral to solving a complex problem. It captured knowledge of various kinds.
• Distilling the model.
• Important concepts were added to the model as it became more complete, but equally important, concepts were dropped when they didn't prove useful or central. When an unneeded concept was tied to one that was needed, a new model was found that distinguished the essential concept so that the other could be dropped.
• Brainstorming and experimenting.
• The language, combined with sketches and a brainstorming attitude, turned our discussions into laboratories of the model, in which hundreds of experimental variations could be exercised, tried, and judged. As the team went through scenarios, the spoken expressions themselves provided a quick viability test of a proposed model, as the ear could quickly detect either the clarity and ease or the awkwardness of expression.
• Knowledge Crunching
• Similar to how financial analysts crunch numbers, effective domain modelers are knowledge crunchers.
• "They take a torrent of information and probe for the relevant trickle. They try one organizing idea after another, searching for the simple view that makes sense of the mass."
• "Good programmers will naturally start to abstract and develop a model that can do more work. But when this happens only in a technical setting, without collaboration with domain experts, the concepts are naive. That shallowness of knowledge produces software that does a basic job but lacks a deep connection to the domain expert's way of thinking."
• "The constant refinement of the domain model forces the developers to learn the important principles of the business they are assisting [...] The domain experts often refine their own understanding by being forced to distill what they know to essentials, and they come to understand the conceptual rigor that software projects require."
• "These models are never perfect; they evolve. They must be practical and useful in making sense of the domain. They must be rigorous enough to make the application simple to implement and understand."
• Continuous Learning
• "When we set out to write software, we never know enough."
• "At this point, stop and ask yourself a question. Did you learn something about the PCB design process? Although this example has been a superficial treatment of that domain, there should be some learning when a domain model is discussed. I learned an enormous amount. I did not learn how to be a PCB engineer. That was not the goal. I learned to talk to PCB experts, understand the major concepts relevant to the application, and sanity-check what we were building."
• Knowledge-Rich Design
• "The kind of knowledge captured in a model such as the PCB example goes beyond "find the nouns." Business activities and rules are as central to a domain as are the entities involved; any domain will have various categories of concepts. Knowledge crunching yields models that reflect this kind of insight. In parallel with model changes, developers refactor the implementation to express the model, giving the application use of that knowledge."
• "Domain experts are usually not aware of how complex their mental processes are as, in the course of their work, they navigate all these rules, reconcile contradictions, and fill in gaps with common sense. Software can't do this. It is through knowledge crunching in close collaboration with software experts that the rules are clarified, fleshed out, reconciled, or placed out of scope."
• An example is given in the domain of booking cargos onto a voyage of a ship.
• Overbooking is a basic strategy in the industry.
• Code examples are given showing how to better reflect and emphasize this business rule as it relates to the domain model.
• "Now, I am not recommending that such an elaborate design be applied to every detail of the domain. Chapter 15, "Distillation," goes into depth on how to focus on the important and minimize or separate everything else. This example is meant to show that a domain model and corresponding design can be used to secure and share knowledge."
• The more explicit design has these advantages:
• In order to bring the design to this stage, the programmers and everyone else involved will have to come to understand the nature of overbooking as a distinct and important business rule, not just an obscure calculation.
• Programmers can show business experts technical artifacts, even code, that should be intelligible to domain experts (with guidance), thereby closing the feedback loop.
• Deep Models
• "Useful models seldom lie on the surface. As we come to understand the domain and the needs of the application, we usually discard superficial model elements that seemed important in the beginning, or we shift their perspective. Subtle abstractions emerge that would not have occurred to us at the outset but that pierce to the heart of the matter."
• "[In the container shipping system] project, because a shipment begins with the act of booking cargo, we developed a model that allowed us to describe the cargo, its itinerary, and so on. This was all necessary and useful, yet the domain experts felt dissatisfied. There was a way they looked at the business that we were missing."
• "Eventually, after months of knowledge crunching, we realized that the handling of cargo, the physical loading and unloading, the movements from place to place, was largely carried out by subcontractors or by operational people in the company. In the view of our shipping experts, there was a series of transfers of responsibility between parties. A process governed that transfer of legal and practical responsibility, from the shipper to some local carrier, from one carrier to another, and finally to the consignee. Often, the cargo would sit in a warehouse while important steps were being taken. At other times, the cargo would move through complex physical steps that were not relevant to the shipping company's business decisions. Rather than the logistics of the itinerary, what came to the fore were legal documents such as the bill of lading, and processes leading to the release of payments."
• "Knowledge crunching is an exploration, and you can't know where you'll end up."

Effective Python Book Review and Book Club Experience

Well, if you want to get an in depth understanding of best practices and how to write Pythonic code with the latest version of Python (3.8 as of this writing), then Effective Python, Second Edition by Brett Slatkin is a good book for doing just that. In addition to giving current best practices, it also present how a number of things were done in the past, which is quite useful if you need to look through legacy code that might not by following all the current best practices. And let's face it, in the world of programming, that's a pretty common occurrence.

As I took the book club through this book, I took things in a bit of a different direction. I had the preparation of practice problems for each chapter, and the presentation of them, assigned out to different member of the book club. I did this for a couple of reasons. First, I know from experience that the one who teaches is the one who learns the most by far, and it was good to spread this opportunity around. Secondly, to be quite honest, it freed up some of my time to focus on other projects on my plate.

In preparation for this, I wrote an article going over how I figured the developer book club could be systematized, which can be seen here:

The Developer Book Club System

Following this, I was the presenter for the first chapter of the book:

Chapter 1: exercise and answer

In addition to this, while coming up with the exercise, I recorded my thought process for coming up with a practice problem, which can be found in this article:

My Thought Process For Creating an Exercise Problem

After this, it was time for others in the group to take a turn. During this process, there were plenty in the group that had vastly different styles of presenting compared to what I typically do, and it gave me an opportunity to learn some of the benefits of these other presentation styles. I wrote up a number of posts covering my thoughts on some of these presentations:

Another Approach to Building Exercise Problems
Presenting by Using Examples from the Book
When Presenting, It can be Worthwhile to Add a Fun Twist to the Problem

It is also worth noting that people stepped up and made it work. The only other presentations that I did for the book were on chapter 8, where I needed to cover for someone due to extraneous circumstances, and the last chapter, chapter 10, where I simply didn't find someone to fill that spot. My practice problems for these chapters can be found here:

Chapter 8: exercise and answer
Chapter 10: exercise and answer

And with that, we've managed to get through another book, and learned a few more things. The group decided that we needed a breather before getting started in on the next book, so we'll plan to take about a month and a half off, during which time we'll work on getting through the busy season for our company, and after that, we'll look into picking up our next book.