You get just what you want and nothing extra.
Temporary contractors can be assigned.
Disadvantages
Ongoing maintenance and training burden.
It is easy to underestimate the time and cost of developing such packages.
Of course, this too combines well with "published design or model."
G
ENERIC SUBDOMAINS
are the place to try to apply outside design expertise, because they do not
require deep understanding of your specialized
CORE DOMAIN
, and they do not present a major
opportunity to learn that domain. Confidentiality is of less concern, because little proprietary
information or business practice will be involved in such modules. A
GENERIC SUBDOMAIN
lessens the
training burden for those not committed to deep knowledge of the domain.
Over time, I believe our ideas
of what constitutes the
CORE
model will narrow, and more and more
generic models will be available as implemented frameworks, or at least as published models or
analysis patterns. For now, we still have to develop most of these ourselves, but there is great
value in partitioning them from the
CORE DOMAIN
model.
Example
A Tale of Two Time Zones
Twice I've watched as the best developers on a project spent weeks
of their time solving the
problem of storing and converting times with time zones. While I'm always suspicious of such
activities, sometimes it is necessary, and these two projects provide almost perfect contrast.
The first was an effort to design scheduling software for cargo shipping. To schedule international
transports, it is critical to have accurate time calculations, and because all such schedules are
tracked in local time, it is impossible to coordinate transports without conversions.
Having clearly established their need for this functionality, the team proceeded with development
of the
CORE DOMAIN
and some early iterations of the application using
the available time classes
and some dummy data. As the application began to mature, it was clear that the existing time
classes were not adequate, and that the problem was very intricate because of the variations
between the many countries and the complexity of the International Date Line. With their
requirements by now even clearer, they searched for an off-theshelf solution, but found none.
They had no option but to build it themselves.
The task would require research and precision engineering, so the team leaders assigned one of
their best programmers. But the task did not require any special knowledge
of shipping and would
not cultivate that knowledge, so they chose a programmer who was on the project on a temporary
contract.
This programmer did not start from scratch. He researched several existing implementations of
time zones, most of which did not meet requirements, and decided to adapt the public-domain
solution from BSD Unix, which had an elaborate database and an implementation in C. He reverse-
engineered the logic and wrote an import routine for the database.
The problem turned out to be even harder than expected (involving, for example, the import of
databases of special cases), but the code got written
and integrated with the
CORE
and the product
was delivered.
Things went very differently on the other project. An insurance company was developing a new
claims-processing system, and planned to capture the times of various events (time of car crash,
time of hail storm, and so on). This data would be recorded in local time, so time zone functionality
was needed.
When I arrived, they had assigned a junior, but very smart,
developer to the task, although the
exact requirements of the app were still in play and not even an initial iteration had been
attempted. He had dutifully set out to build a time zone model
a priori
.
Not knowing what would be needed, it was assumed that it should be flexible enough to handle
anything. The programmer assigned to the task needed help with such a difficult problem, so a
senior developer was assigned to it also. They wrote complex code, but no specific application was
using it, so it was never clear that the code worked correctly.
The project ran aground for various reasons, and the time zone code was never used. But if it had
been, simply storing local times tagged with the time zone
might have been sufficient, even with
no conversion, because this was primarily reference data and not the basis of computations. Even
if conversion had turned out to be necessary, all the data was going to be gathered from North
America, where time zone conversions are relatively simple.
The main cost of this attention to the time zones was the neglect of the
CORE DOMAIN
model. If the
same energy had been placed there, they might have produced a functioning prototype of their
own application and a first cut at a working domain model. Furthermore,
the developers involved,
who were committed long-term to the project, should have been steeped in the insurance domain,
building up critical knowledge within the team.
One thing both projects did right was to cleanly segregate the
GENERIC
time zone model from the
CORE DOMAIN
. A shippingspecific or insurance-specific model of time zones would have coupled the
model to this generic supporting model, making the
CORE
harder to understand (because it would
contain irrelevant detail about time zones). It would
have made the time zone
MODULE
harder to
maintain (because the maintainer would have to understand the
CORE
and its interrelationship with
time zones).
Do'stlaringiz bilan baham: 
