For many who
have escaped from the perils of large, upfront analysis and design phases to
the freedom and discipline of Scrum and eXtreme Programming-inspired
approaches, the idea of developing a domain object model at the start of a
project is controversial. In FDD, however, the building of an object model is
not a long, drawn-out, activity performed by an elite few using expensive CASE
tools. The modelers do not format the resulting model into a large document and
throw it over the wall for developers to implement.
Instead,
building an initial object model in FDD is an intense, highly iterative,
collaborative and generally enjoyable activity involving ‘domain and
development members under the guidance of an experienced object modeler in the
role of Chief Architect' [Nebulon ]. FDD Process #1 describes the tasks and
quality checks for executing this work, and while not mandatory, the object
model is typically built using Peter Coad's modeling in color technique
(modeling in color needs an introductory article all of its own [Palmer-2 ]).
The idea is for
both domain and development members of the team to gain a good, shared
understanding of the problem domain. It is important that everyone understands
the key problem domain concepts, relationships, and interactions. In doing so,
the team as a whole learn to communicate with each other and start to establish
a shared vocabulary, what Eric Evans calls a Ubiquitous Language [Evans]. The
object model developed at this point concentrates on breadth rather than depth;
depth is added iteratively through the lifetime of the project. The model is,
therefore, a living artifact. Throughout the project, the model becomes the
primary vehicle around which the team discusses, challenges, and clarifies
requirements.
Nenhum comentário:
Postar um comentário