Architecture Patterns for FAIR-Enabling Services

I’ve been trying to grok architecture patterns as presented by Percival and Gregory1 to support domain-driven design and event-driven microservices with Python. I hope you find the diagram below useful.

Relating domain-driven design, event-driven microservices, command-query responsibility segregation (CQRS) + views, and validation (of syntax, semantics, and pragmatics)

A microservices approach seems apt for FAIR-enabling services that need to be composed, flexibly, for any given research artifact’s digital lifecycle. Consider these services:

Consider how you may want to swap one technology choice for a given FAIR-enabling service with another choice, at any time, as part of evolving FAIR infrastructure to which you connect in order to collaborate on and publish / share research artifacts.

  1. H. J. W. Percival and R. G. Gregory, Architecture patterns with Python: enabling test-driven development, domain-driven design, and event-driven microservices, First edition. O’Reilly, 2020. (available online). ↩︎

  2. Example: “Arklet - A basic ARK resolver.” Internet Archive, Oct. 14, 2022. Accessed: Oct. 17, 2022. [Online]. Available: ↩︎

  3. principle addressed: F — Findable, A — Accessible, I — interoperable, R — reusable. ↩︎

  4. Example: “Elasticsearch”. ↩︎

  5. Example: “Amazon Simple Storage Service (Amazon S3)”. ↩︎

  6. Example: “Transactor | Datomic.” (accessed Oct. 17, 2022). ↩︎

  7. Example: “DataHarmonizer.” Centre for Infectious Disease and One Health, Aug. 08, 2022. Accessed: Oct. 17, 2022. [Online]. Available: ↩︎

  8. Example: “git - the stupid content tracker.” (accessed Oct. 17, 2022). ↩︎