Modularity is critical to industrialize differentiated experience

Modularity is perhaps the most essential architecture principle applied across the Adobe® Digital Enterprise Platform (ADEP). Modularization in ADEP enables you to manage the complexity of your CEM solutions by separating them into independent components and other concerns that can be worked on by different development teams and tested in isolation. When deployed, these solutions consume minimal footprint that is associated with specific workload requirements (i.e. resource usage is kept to what is essential for delivering business value).


The very nature of differentiated customer experience is modular–my experience today should differ from my experience tomorrow, from my experience yesterday and from what another customer may experience. ADEP anticipates, is tuned for and can accelerate composition and reuse. In an enterprise context, supporting such modularity means that you can draw upon the breadth of assets (content, applications, documents, processes, services) available, including those from Adobe, Adobe’s partners, systems integrators, agencies and other teams within your enterprise. These assets can be brought to bear on business problems in a manner that can be partitioned and rolled out incrementally with minimal disruption (e.g. hot deployment[1]).

Modularity in ADEP is a form of separation of concerns that provides both logical and physical encapsulation of classes. Modularity is desirable because it allows you to break applications into logically independent pieces that can be independently changed and reasoned about. Modularity enables division of labor across a solution, and it promotes abstraction, reuse and ease of maintenance and repair.

As a consequence of embracing modularity as a core architecture principle, software modules in ADEP are self-contained (local wholes), highly cohesive (fulfill single purposes) and loosely coupled (well-isolated from other modules).

To support all three properties, it is vital for modules to have a well-defined interface for interaction with other modules. A stable interface enforces logical boundaries between modules and prevents access to internal implementation details. Ideally, the interface should be defined in terms of what each module offers to other modules, and what each module requires from other modules.

Modularity is driven across the ADEP architecture via the following principles:

  • Interface-based programming[2]
  • Externalization of cross-cutting concerns (aspect-oriented programming[3])
  • Late binding of implementation instances to interfaces (dependency injection;[4] extensibility)

Next: everything is content.

Update 9/6/2011: The larger technical white paper from which this post was drawn is now available from the ADEP Developer Center as a PDF download. Please feel free to provide me with your feedback on that work here. Thanks in advance!

[1] i.e. a provision of dynamic modularity in an OSGi-based system like ADEP
[2] Please consider Interface Oriented Design for a more detailed discussion of interface-based programming.
[3] Please consider AspectJ in Action: Enterprise AOP with Spring Applications, Second Edition for a more detailed discussion of aspect-oriented programming (AOP).
[4] Please consider Dependency Injection: Design patterns using Spring and Guice for a more detailed discussion of dependency injection (DI).