This chapter is from the book
This chapter is from the book
This chapter is from the book
How This Book Is Organized
This book is divided into three parts. Part I presents the case for modularity. Here, you explore the important role that software modularity plays in designing software systems and learn why you want to design modular software. Part II is a catalog of 18 patterns that help you design more modular software. These patterns rely heavily on the ideas discussed in Part I. Part III introduces OSGi and demonstrates how a software system designed using the patterns in this book is well positioned to take advantage of platform support for modularity. Part III relies heavily on code examples to demonstrate the points made.
Naturally, I suggest reading the book cover to cover. But, you might also want to explore the book by jumping from chapter to chapter. Feel free! Throughout this book, in the margin, you’ll notice several forward and backward references to the topics relevant to the current topic. This helps you navigate and consume the ideas more easily. The following is a summary of each chapter.
Part I: The Case for Modularity
Part I presents the reasons why modularity is important. It is the case for modularity. A brief synopsis of each chapter in Part I follows:
- Chapter 1, “Module Defined”: This chapter introduces modularity and formally defines and identifies the characteristics of a software module. I encourage everyone to read this short chapter.
- Chapter 2, “The Two Facets of Modularity”: There are two aspects to modularity: the runtime model and the development model. Much emphasis has been placed on providing runtime support for modularity. As more platforms provide runtime support for modularity, the importance of the development model will take center stage. The development model consists of the programming model and the design paradigm.
- Chapter 3, “Architecture and Modularity”: Modularity plays a critical role in software architecture. It fills a gap that has existed since teams began developing enterprise software systems. This chapter examines the goal of software architecture and explores the important role modularity plays in realizing that goal.
- Chapter 4, “Taming the Beast Named Complexity”: Enterprise software systems are fraught with complexity. Teams are challenged by technical debt, and systems are crumbling from rotting design. This chapter explains how modularity helps us tame the increasing complexity of software systems.
- Chapter 5, “Realizing Reuse”: Reuse is the panacea of software development. Unfortunately, few organizations are able to realize high rates of reuse. This chapter examines the roadblocks that prevent organizations from realizing reuse and explores how modularity increases the chance of success.
- Chapter 6, “Modularity and SOA”: Modularity and SOA are complementary in many ways. This chapter explores how modularity and SOA are a powerful combination.
- Chapter 7, “Reference Implementation”: It’s important to provide some decent samples that illustrate the concepts discussed. The reference implementation serves two purposes. First, it ties together the material in the first six chapters so you can see how these concepts are applied. Second, it lays the foundation for many of the patterns discussed in Part II.
Part II: The Patterns
The patterns are a collection of modularity patterns. They are divided into five separate categories, each with a slightly different purpose. There is some tension between the different categories. For instance, the usability patterns aim to make it easy to use a module while the extensibility patterns make it easier to reuse modules. This tension between use and reuse is further discussed in Chapter 5.
- Chapter 8, “Base Patterns”: The base patterns are the fundamental elements upon which many of the other patterns exist. They establish the conscientious thought process that go into designing systems with a modular architecture. They focus on modules as the unit of reuse, dependency management, and cohesion. All are important elements of well-designed modular software systems.
- Chapter 9, “Dependency Patterns”: I’ve personally found it fascinating that development teams spend so much time designing class relationships but spend so little time creating a supporting physical structure. Here, you find some guidance that helps you create a physical structure that emphasizes low coupling between modules. You’ll also find some discussion exploring how module design impacts deployment.
- Chapter 10, “Usability Patterns”: Although coupling is an important measurement, cohesion is equally important. It’s easy to create and manage module dependencies if I throw all of my classes in a couple of JAR files. But in doing so, I’ve introduced a maintenance nightmare. In this chapter, we see patterns that help ensure our modules are cohesive units. It’s interesting that you’ll find some contention between the dependency patterns and usability patterns. I talk about this contention and what you can do to manage it.
- Chapter 11, “Extensibility Patterns”: A goal in designing software systems is the ability to extend the system without making modifications to the existing codebase. Abstraction plays a central role in accomplishing this goal, but simply adding new functionality to an existing system is only part of the battle. We also want to be able to deploy those new additions without redeploying the entire application. The extensibility patterns focus on helping us achieve this goal.
- Chapter 12, “Utility Patterns”: The utility patterns aid modular development. Unlike the other patterns, they don’t emphasize reuse, extensibility, or usability. Instead, they discuss ways that modularity can be enforced and that help address quality-related issues.
Part III: POMA and OSGi
Standard Java gives you everything you need to begin using the patterns in this book. Undoubtedly, though, you want to see the patterns in the context of an environment that provides first-class support for modularity. In this section, we do just that and use the OSGi framework to illustrate this through example.
- Chapter 13, “Introducing OSGi”: This chapter provides a brief introduction to OSGi, including its capabilities and benefits. This chapter isn’t meant as a tutorial and assumes some cursory knowledge of OSGi. We talk about OSGi and modularity, including μServices and the Blueprint specification. Additionally, you’ll see how the dynamism of OSGi brings modularity to the runtime environment. Finally, we wrap up by exploring how the patterns relate to development in OSGi. We point out how OSGi makes it easier to use some of the modularity patterns in their purest form.
- Chapter 14, “The Loan Sample and OSGi”: As you read through the pattern discussions, you’ll notice a common example we use is a loan system. In this chapter, we again use the loan system but refactor the application so that it runs in an OSGi environment. You’ll be surprised that once you have a modular architecture, OSGi is just a simple step away.
- Chapter 15, “OSGi and Scala”: The Java platform supports multiple languages, and OSGi doesn’t inhibit you from using alternative languages on the Java platform. In this section, we show how we can create a Scala module and plug it into a system. You’ll see two simple advantages. First, the modular architecture makes it easy to add code without making modifications to any other code in the system. Second, it clearly illustrates the dynamism of OSGi.
- Chapter 16, “OSGi and Groovy”: Like the Scala example in Chapter 15, we develop another module using the Groovy programming language to further illustrate the flexibility and dynamicity of a runtime environment that supports modularity.
- Chapter 17, “Future of OSGi”: What’s the future of modularity and OSGi? How might it transform how we currently think about large enterprise software systems? In this chapter, we explore that future with a provocative look at what’s in store for modularity and OSGi.