Hi Joe -- You asked...

> Is there anything inherent in DNC or FDD
> that leads to a breakdown of Features
> that suggests the use of the MVC pattern...?

To some extent, yes. The DNC is focused on the
*problem* domain (essentially the Model in MVC).
Typically, FDD and DNC practitioners have separated
user interfaces (UI), system interfaces (SI),
and data management (DM) or persistence matters
into affiliated layers and/or components.

Certainly, you will have some requirements around
certain interfaces, and a given business problem
"model" may be integrated with multiple user interfaces.
Be careful to separate problem (apply DNC) and context
(everything else).

You also wrote...
> I have a Feature List now that has Major Feature Sets
> of Search Management and Result View Management.
> I am struggling with the Features.

OK so far. To get help with Features,
have you looked to the *feature syntax* template
to help you think like a problem domain object?

(action request)...(return result)...(object context)
for example,
find the owner(s) of a registered-vehicle

I gather that you are working with existing tables.
Look at the entity tables and see if any of those
suggest a party, place, or thing? The greens.
Are there tables of events, moments or intervals
of dates/times? Those would suggest pinks.

Registrations, titles, primary driver as listed
on an insurance policy...all those are pink.
In your database, they might be built as some
kind of join table or association set.

In your idealized DNC world, you could ask
a vehicle to tell you who its owners are.
Try thinking that way, and see if it helps
you come up with some Features. Actually,
they will look like methods (operations)
on objects in your problem domain model.

Nearly all of the uniqueness of any
application is reflected in its problem
domain model, as reflected in the DNC.

You can do similar thinking for "technical"
features (non-business) such as the Views.
The DNC will not give you much help there.
However, the patterns for UI, SI, and DM
mappings are the most frequently recurring
and the examples you see in all kinds of
packages. Once you have your problem model
figured out, the UI, SI, DM are bolt-ons.

For instance, you can look at your model,
come up with a data mapping between your
problem domain model and database tables,
to persist the business objects that must
be retained when the DNC's lights go out.
Object-relational mapping is the focus of
tools such as Hibernate (and NHibernate).

MVC-inspired kits (Struts, Spring, et al)
are available in multiple flavors...
Model 1, model 2, and so on.

So, go back to your requirements and try
finding *business* features which look
like methods on problem domain classes.
Then, add technical layers and features.
Then, try an implementation or two.

I hope this helps.

Cheers,
--ken ritchie, atlanta
senior coad certified mentor
www.linkedin.com/in/kenritchie



-----Original Message-----
From: colormodeling@yahoogroups.com
[mailto:colormodeling@yahoogroups.com]On Behalf Of jjrancourt
Sent: Tuesday, March 18, 2008 9:00 AM
To: colormodeling@yahoogroups.com
Subject: [colormodeling] DNC to MVC


Users want some simple fixed queries (1 or 2 filters/parameters,
default table result view) and some advanced queries (lots of filter
options and View options - tables, timeline, map, links).

I have been experimenting and am enjoying the DNC thought process
(model by take away). I am also working an Agile Project's
requirements for the first time and looking at FDD.

Is there anything inherent in DNC or FDD that leads to a breakdown of
Features that suggests the use of the MVC pattern or is that purely a
design choice? This seems like such a standard problem, I thought
maybe you all had an "archetype" DNC / Feature List breakdown for
Search-View in cases where the MVC pattern obviously fits well.

I have a Feature List now that has Major Feature Sets of Search
Management and Result View Management. I am struggling with the
Features.

Thanks, Joe Rancourt





------------------------------------

Yahoo! Groups Links