Do I understand the process of building a hApp correctly if I understand it to be:
To develop a solution, reduce that system to its smallest possible components and either find those existing implementations or build each element as necessary, assemble the final product as a DNA which calls sub DNAs into a final hApp which accomplishes my fundamental intent?
Awesome, glad you found that valuable. I think you’d be on the right track with what you described – there’s an impending update to that article; you can read the draft in this Git pull request.
I suspect our modularity story – when something should be a ‘zome’ or a ‘DNA’ or a full ‘hApp’ – but here are some pointers:
Package your code in a Rust crate for optimal code reuse.
Package your code in a zome for encapsulation (implementation hiding, etc) and reuse in other DNAs.
Package multiple zomes into one DNA for privacy/isolation/cloneability (each DNA has its own private DHT, and can be ‘cloned’ multiple times to create separate spaces with the same business logic) and configurability (you can redefine DNA properties at install time; these properties are like environment variables that makes the code work differently).
Because a DNA can be accessed by multiple UIs, make sure the code that’s really important for ensuring data integrity (correct formatting, constraints on inputs, permissions/privileges, etc) is in your zome/DNA code.
