Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture (Addison-Wesley Signature Series (Vernon))

Modularity is an indispensable foundation for Conway’s Law as well. That’s because modules are where we should capture critical communication and what is learned from it. At the same time, modules can save teams from smearing mud all over their solution space. Modules are used both as conceptual boundaries and as physical compartments.

Domain-driven points out that a business drives results through investments in knowledge acquisition within and beyond its current sphere of influence and activity. The business drives its own advancement and growth through steady improvements in its technology-based products. This book continually asserts that it is learning through experimentatio

A business capability answers the “What?” question regarding the means by which the company will generate revenues. A substantive question with regard to a business capability is “How?” Impact Mapping, discussed in Chapter 2 in the section “Strategic Delivery on Purpose,” explains driving software deliverables starting with the question “Why?” By t

Even so, problems will occur when trying to apply Bounded Contexts with distributed computing before the teams have a good reason to, or when trying to understand the strategic goals and solve business problems using single-process modularity first. Such a bias will likely lead to over-engineered technical approaches, putting too much emphasis on t

As an example of using a methodology or process execution framework, Scrum identifies four primary reasons to place an item in the product backlog: Features Bugs Technical Work Knowledge Acquisition It’s disappointing that Knowledge Acquisition is consigned to last place, because it should always be in first place. How can a team place a new featur

Early on, it is best to choose a deployment option that supports fast experimentation, implementation, and delivery. This specifically points to using a Monolithic architecture in the early stages, because trying to solve distributed computing problems before the business problems are understood is an act of futility.

When the team has decided on modules first, and when deployment options start out as simple as possible, that approach puts them on solid ground to make decisions based on empirical information at the most responsible time.

Spaghetti business always exists before software, and spaghetti code is the bane of a system’s existence. Ad hoc architecture, progressive distortion of the software model, wrongly chosen abstractions, seeking opportunities for code reuse before use is even achieved, and unskilled developers are some of the reasons that software complexity prevents

This is a good place to introduce the idea of using an engineering model approach to software development as opposed to the contractor model. First consider the typical contractor model. Under this model, whether used by employees or actual contractors, developers must be given accurate tasks to work on, and they must not fail in even small ways. T