Great series so far! I'd like to know your thoughts about reusing the same Beer model across all the modules. What are your thoughts about having different models for each module and using a mapper. ie: have different structs for the backend model and the model used by the UI
Good question - personally, I think it’s usually overkill to have separate ‘internal’ versions of each model per module. But this isn’t something I’ve ever really done - I’d be interested to hear your take on when this could be appropriate and the positive trade-offs you get in exchange for a little bit more code.
However, a very common pattern I usually apply is having separate DTOs (data transfer objects) in either your Domain/Networking module that translate whatever your API schema is into what your app can use most easily.
In this particular case, I agree with you that it'd be an overkill without any particular benefit. However, I was thinking in some scenarios where:
a) The backend model and the domain model do not match 100%
b) You have different feature modules that might be shared across different apps
I think in both of those scenarios, having internal per-module models could be a great idea to improve modularization and reutilization of the modules, without coupling a lot of modules together just for the model sharing capabilities.
However, I'm usually more incline to follow the "easiest to follow and maintain" approach over the best "theoretical" approach. So I think having one module at the bottom of the graph with all the backend/domain shared models sounds like a great idea!
Would it be better to create initializers using generics instead of using the protocol directly since using the protocol would result in a boxed type and have a performance penalty?
Great series so far! I'd like to know your thoughts about reusing the same Beer model across all the modules. What are your thoughts about having different models for each module and using a mapper. ie: have different structs for the backend model and the model used by the UI
Hey Muralla, thanks for the compliment 😄
Good question - personally, I think it’s usually overkill to have separate ‘internal’ versions of each model per module. But this isn’t something I’ve ever really done - I’d be interested to hear your take on when this could be appropriate and the positive trade-offs you get in exchange for a little bit more code.
However, a very common pattern I usually apply is having separate DTOs (data transfer objects) in either your Domain/Networking module that translate whatever your API schema is into what your app can use most easily.
Hi Jacob, thanks for replying.
In this particular case, I agree with you that it'd be an overkill without any particular benefit. However, I was thinking in some scenarios where:
a) The backend model and the domain model do not match 100%
b) You have different feature modules that might be shared across different apps
I think in both of those scenarios, having internal per-module models could be a great idea to improve modularization and reutilization of the modules, without coupling a lot of modules together just for the model sharing capabilities.
However, I'm usually more incline to follow the "easiest to follow and maintain" approach over the best "theoretical" approach. So I think having one module at the bottom of the graph with all the backend/domain shared models sounds like a great idea!
Would it be better to create initializers using generics instead of using the protocol directly since using the protocol would result in a boxed type and have a performance penalty?