Subsystems In Xp

I am trying to understand how to apply ExtremeProgramming, particularly in a C++ context, and something I am curious about is the overall structure or architecture of ExtremeSoftware. Currently, when we design a system we break down the functionality of the system into subsystems and then break the subsystems down into service packages. Each service package is then implemented using one or more classes along with their unit tests.

It is very important in our process to manage the dependencies between the subsystems and between the packages in order to end up with a layered structure. In general (and particularly for infrastructure packages) we will split a package into an interface package (which defines some abstract base classes) and an implementation package which provides a default implementation.

I am interested in whether the concept of subsystems and service packages exists in the ExtremeProgramming methodology and if so whether the structure is determined up front or evolves over time. Is there any concept of splitting functionality up into interface and implementation packages? Or does this go against DoTheSimplestThingThatCouldPossiblyWork and would only come about as a result of refactoring at the time it was actually needed?

-- JamesCrawford

Subsystems and service packages and their analogues in other languages are tools that you might apply. We would generally not spend much time up front on them unless they were identified as a risk (see WorstThingsFirst). Since XP generally leads to a small system that grows to be what you want, the packaging generally only shows up later on in the project.

We have not to date had a lot to say about deployment, stripping for release, etc. Some attention to packaging up front might be desirable, but I would hold it well below what most people would consider the minimum. The main reason for this is that I expect the product itself to evolve far from where it was originally envisioned. Most everything about the packaging decisions is likely to be wrong. --RonJeffries

I don't really know enough of how Smalltalk works and maybe with the appropriate tools it isn't a problem, but where I work the package and subsystem structure is mapped into a directory structure that is then placed under source code control using CVS. With each class name being reflected in its file name and each package being a directory name, changing the names of classes, moving classes between packages, and renaming packages causes enough heartache with CVS that it would be a major impediment to refactoring. There must be a better way... -- JamesCrawford

Further discussion moved to RefactoringWithCvs.