Part II: Driving Business Innovation

Executive Summary

In Part I, we established the goals of pursuing digital transformation as a revenue-generating business strategy, and applying the proper mindset, culture, and learning tools to facilitate this effort. Now it’s time to delve into a software development technique that promotes and upholds the value-generating goals. It helps businesses understand where strategic investments should be made, and where they should not.

The technique and practices advanced in this part of the book are readily adoptable. To provide a brief summary, this approach acknowledges that differences in perceptions and viewpoints within business capabilities and processes are not only common, but necessary. That is, depending on the context of an area of business expertise and the specific communication that occurs there, what might appear to be equivalent concepts may, in fact, be vastly different or have a critical nuance of difference from other viewpoints. As an example, consider the concept of policy inside NuCoverage. There are various meanings for this term, because in reality policy is not a single concept, but many. To understand the differing concepts with the same name, the term policy must be surrounded by the context in which it has a given meaning and set of business rules.

Admittedly, when you’re introducing a “new way” of approaching software development, there’s a danger in it being viewed as yet another shiny object. With that being said, it’s notable that this technique is not at all new. The concepts are more than two decades old, and the proposed technique codifies the essence of several worthwhile practices that have been used for additional decades. The authors have decided to promote not the name, but rather the practices used with this approach. That’s because names can be misused to describe the use of poor practices, and sadly that has been the case with this technique for a while now. Like anything, people want to be associated with success, but often don’t want to put in the effort necessary to understand and practice the technique as intended. Throwing together some words is meant to elevate them to the “club,” whatever that is supposed to mean. Yet, if the practices are the focus of this book, then chances are better that the practices will be adopted rather than a name only.

The other choice is to do what most software teams are prone to do: attempt to merge the clearly recognizable differences between one term used in multiple contexts of human thought and communication into a single unified thing. That kind of merger has proven problematic and even damaging time and again, and it most often leads to the large, gnarly, mud-like software that such great effort is being spent to defeat. Intake of an application to obtain a policy, calculating the risk and premium rate of a potential policy, underwriting a policy, filing a claim against a policy, and renewing a policy are all very different concepts, and they should be modeled differently in separate software contexts. The technique and practice offered in Part II uses separate module-based software contexts to host the range of different uses.

Chapter 4: Reaching Domain-Driven Results

The word domain, as used in this book, refers to a sphere of knowledge. As already established, knowledge is one of the most valuable assets of any business.

▪ Existing knowledge is important and valuable, but a business that rests on its current knowledge risks that it is ordinary, or that even new, breakthrough knowledge can become ordinary if and when the competition catches up. Continuous knowledge acquisition must be at the top of the software requirements list.

▪ When a sphere of knowledge is identified by a name, this domain has preexisting knowledge. The trick is not just to continue to acquire knowledge in the preexisting subsystems, but also to gain new breakthrough knowledge in the areas of anticipated innovation.

▪ A domain names and encompasses a problem space—that is, an area of the enterprise where new software concepts will deliver competitive advantage. Each of the subparts of the problem space domain are logically known as subdomains, and two or more of these will be used to establish industry leadership for the innovator.

▪ A single subdomain is a contextual division where a given area of business expertise can be explored and developed. Multiple subdomains each reflect a different context of expertise.

▪ Consider the abstractions in Chapter 4 as being the opposite of plug-in, all-too-familiar business capabilities. Concrete examples follow in Chapter 5.

Chapter 5: Contextual Expertise

There are generally multiple perspectives in a single problem space domain. Different business experts view the problem space from different angles. The differences in perspectives are where the contextual divisions are likely to be established.

▪ A contextual division of expertise forms a perimeter around the project and team responsible for it. The boundary is established to keep terms, meanings, and business rules consistent within and to prevent any other terms, meanings, and business rules from infiltrating and causing corruption by outside forces.

▪ Within a contextual boundary of expertise, the terms, meanings, and business rules used by the single responsible team working in that area form a special team language. This language is ubiquitous inside the boundary because it is regularly expressed orally by the team, written in documents, and drawn in diagrams, and the source code of the software model reflects the language.

▪ A contextual division that is formed around an area of highest strategic importance and investment is known as the core. To make known the difference between the core and those contexts deemed worthy of lesser investment, the names supporting and generic are used for the latter. Generally, supporting subdomains must be developed internally or outsourced, but will not receive deep intellectual investment. Generic subdomains may be purchased or downloaded from open source venues.

▪ Business capabilities are a good place to look when establishing contextual boundaries. Although there can be finer divisions of expertise, the contexts can be first chosen as business capabilities. When finer-grained areas of expertise are recognized, those can be extracted from an initial business capability context. This points to the importance of understanding the organization-specific business capabilities.

Chapter 6: Mapping, Failing, and Succeeding—Choose Two

Because there will always be multiple business capabilities, and related contextual areas of expertise, it’s critical to understand how to interact and integrate with the software models found in other context boundaries. This requires a clear understanding of the team dynamics between any two teams, as well as which facilities are available for integration. One set of techniques to support such efforts is known as mappings. It’s important to use these and other domain-driven techniques properly, or negative outcomes can occur.

▪ Maps are drawings that represent reality.

▪ Drawing lines between any two contextual boundaries to indicate a relationship between them creates a map. Maps are good choices for displaying directions, flow, and any travel complexities.

▪ The lines drawn between any two context boundaries represent the existing inter-team relationship, direction of dependencies, and a means of integration.

▪ There are eight different ways that two contexts can be mapped, which are not mutually exclusive.

▪ An additional topographical mapping tool is provided in Chapter 6, which helps show specific integration points and concrete examples between any two or more contexts.

▪ Existing inter-team relationships that are not ideal might be changed if the status quo causes unworkable circumstances. The existing situation must first be understood and identified to recognize how it must change for the better.

▪ Fair warnings are provided to use the given tools properly, as opposed to circulating a technique name in an attempt to become a club member. Before any team jumps in, make sure they understand these points of potentially unrecoverable failure, and how to avoid them.

Chapter 7: Modeling Domain Concepts

When it comes to actual software implementation, a few powerful tools can be applied to implement domain models.

▪ Entities model unique things and generally support other software components making changes to their data. Because of their uniqueness, one entity can be easily distinguished from another.

▪ Value objects are like currency. Paper money contains a number of images, numbers, and other qualities, such as the type of paper and ink, but in the end most people only care about its purchasing value. Furthermore, most people couldn’t care less about which paper note with a value of 5 that they have, and would willingly exchange one 5 note for another. In other words, a value is a value is a value. Many things in software can be modeled as values, and far more should be than actually are in practice.

▪ Aggregates are entities that have a special purpose—namely, representing a set of data that per business rules must remain consistent at all times. The consistency rules are maintained both when in operation on a computer and when stored in a database.

▪ Domain services provide business logic that operates on entities, aggregates, and value objects, but are not directly associated with any one of the types on which they work.

▪ Functional behavior provides the kind of software operations that are like mathematical functions. These operations are meant to take one or more input parameters and produce an answer that is consistent with its mathematical properties.

That was neither mysterious nor intimidating. This knowledge-driven software development approach is straightforward and facilitates differences in perspectives between business experts that might appear to be one and the same thing. It also helps businesses understand where strategic investments should be made, and where they should not.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
54.89.24.147