I have been re-reading Domain-Driven Design after watching several InfoQ presentations given by Eric Evans as well as an interview of Eric at QCon in San Francisco in 2008. There were several core concepts that really stuck out to me as I was watching these in one sitting.
One of the key points that really stuck out to me for some reason was the concepts surrounding "strategic design" and the need to break down that design into parts. Obviously breaking things down is critical but the way in which they're broken down is important.
Generic Subdomain
When you're writing or re-writing an enterprise application, there are going to be parts of the system that facilitate the business, but are not core to the business. For example, in most businesses there is a concept of invoicing—sending bills to customers. While this is a critical business concept, it is not "core" to the business.
In general, these types of pieces can be purchased from a vendor or outsourced (I can't believe I just said that) and then wrapped in such a way to communicate with the rest of the enterprise as necessary.
Supporting Subdomain
These types of pieces are also necessary because they help perform ancillary or, well, supporting functions related directly to what the business does. In these cases, high-quality code and perfectly designed structure are not necessary. You could get by with assigning more inexperienced developers or even, dare I say, outsourcing these pieces.
Just be sure that these concepts do not bleed into your core domain—you want to maintain a rigid separation with a context map to keep separate things separate.
Core Domain
Eric asks several questions to help us identity which parts are core to the domain:
- What makes the system worth writing?
- Why not buy it off the shelf?
- Why not outsource it?
The core domain is so critical and fundamental to the business that it gives you a competitive advantage and is a foundational concept behind the business.
This is the domain that you want your most experienced people working on, instead of having them work complex (and fun) technical or infrastructure problems.
As Eric puts it into numbers, the Core domain should deliver about 20% of the total value of the entire system, be about 5% of the code base, and take about 80% of the effort.