This message was deleted.

Can you explain a bit clearer the difference between approach 1 and 2? For me, both sound like the exact same thing. One project per feature.

Let's assume that we have a chat functionality. With the first approach we are going to have a

feature-chat

module. With the second approach we are going to have

feature-chat-models

,

feature-chat-use-cases

,

feature-chat-database

,

feature-chat-navigation

,

feature-chat-ui

, etc. I ve seen cases where they have in every module 2-3 classes per module which seems odd and counterproductive.

That might indeed be a little overkill. But that is probably then less a performance question, but more an architectural question. Sounds more like a desperate try to micro-optimize without measured problem which is evil. 🙂 If the feature has a public api to be used by other features and you are not using JPMS to restrict the access, it might be a good idea to at least split out the api into an own feature variant or project.

Thank you for your response. To be honest I agree with you. More perspective was needed on this matter 🙂

Ive worked with both approach and I can tell that second one works smoothly and really nice in large scale applications with some dozens of developers working on the same codebase. I currently work at Airbnb and we take a lot of advantage of micro feature modules ui, navigation, core per feature. Also that allows us to load only modules we'll be working on, increasing build speed. So is up to you and your team what best suits for you

Thank you Daniel for your response. Do you have in Airbnb some guidelines that you can share with us about how you break your code into modules (maybe in a blogpost or a sample project)?

No I don't, but I can write a blog post for sure and let you know!

This would be great! Thank you! 🙂