Agenda for HydraDAM architecture meeting, 8/8/16

agenda_for_HydraDAM_architecture_meeting_8-8-16.md

Agenda for HydraDAM architecture meeting, 8/8/16

1. Is it OK if HydraDAM consists of multiple sub-components, even separate rails engines?

Conclusion: Yes, that is ok. There are no use cases for disallowing HydraDAM to be comprised of sub-components.

1. Modeling

2. Do we want multiple top-level models (i.e. registered concerns, a.k.a. "work types") as part of HydrDAM data model?

**Conclusion:** No. Right now, we want HydraDAM (and it's possible subcomponents) to consist of behaviors that can be implemented (i.e. "installed") for models that already exist within a CurationConcerns application.

At this time, we do not want HydraDAM to prescribe specific model types. Note that this differs in the way that `book_concerns` prescribes a model specifically named `Book` that then receives all the behaviors that a `Book` model would have.

1. Do we want to continue using our FileSet modeling strategy (similar to AIC) or push forward with a new, multi-file Fileset object

**Conclusion:** Yes, for the time being. If a data model emerges quickly from the HydraDAM discussions, then we can revisit this question. But for now, stick with what we have.

1. Is there any reason to not emulate book_concerns in the way it is organizing code?, e.g. separation of metadata schema from other behaviors.

Conclusion: Not really. However, as mentioned above, the HydraDAM data model will not prescribe specific work types, so there may be differences in organizational structure because of that difference, and possibly others.