Domain-Driven Design: Tackling Complexity in the Heart of Software

, and avoid assigning your core developers to the tasks (because they
will gain little domain knowledge from them). Also consider off-the-shelf solutions or
published models for these 
GENERIC SUBDOMAINS
.
You may have a few extra options when developing these packages.
Option 1: An Off-the-Shelf Solution
Sometimes you can buy an implementation or use open source code.
Advantages
Less code to develop.

---

Maintenance burden externalized.
Code is probably more mature, used in multiple places, and therefore more bulletproof and
complete than homegrown code.
Disadvantages
You still have to spend the time to evaluate it and understand it before using it.
Quality control being what it is in our industry, you can't count on it being correct and stable.
It may be overengineered for your purposes; integration could be more work than a
minimalist homegrown implementation.
Foreign elements don't usually integrate smoothly. There may be a distinct 
BOUNDED CONTEXT
.
Even if not, it may be difficult to smoothly reference 
ENTITIES
from your other packages.
It may introduce platform dependencies, compiler version dependencies, and so on.
Off-the-shelf subdomain solutions are worth investigating, but they are usually not worth the
trouble. I've seen success stories in applications with very elaborate workflow requirements that
used commercially available external workflow systems with API hooks. I've also seen success with
an error-logging package that was deeply integrated into the application. Sometimes 
GENERIC
SUBDOMAIN
solutions are packaged in the form of frameworks, which implement a very abstract
model that can be integrated with and specialized for your application. The more generic the
subcomponent, and the more distilled its own model, the better the chance that it will be useful.