YT YouTube2Text

YouTube2Text → Transcripts → Vertical vs. Horizontal Slicing - The ONLY Right Way to Split Down Your App

Vertical vs. Horizontal Slicing - The ONLY Right Way to Split Down Your App — Transcript

by Philipp Lackner · 2,710 words · 415 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Hi guys, and welcome back to a new
0:01video. Today we're going to take a look
0:03at vertical versus horizontal slicing
0:05for your mobile app. What should you
0:07actually stick to? If these terms are
0:09new to you, then don't no worries. I
0:11will actually go over exactly that in
0:13this video. And after watching this
0:14video, you will know exactly how you
0:17should actually take a big project and
0:19split this down and which parts of the
0:21app to approach in which order. But
0:23first of all, to just get the
0:24terminology right, vertical and
0:26horizontal slicing, maybe you've heard
0:27that before, but in the end, it's all
0:29about when you have a big project and
0:32you need to split this down into smaller
0:33parts in some way. There are of course
0:35multiple approaches that can work,
0:37multiple approaches to actually slice
0:39the app. And one of them is
0:41horizontally, and one of them is
0:43vertically. Vertical slicing in the end
0:45means if we have our app here, so this
0:47whole square would be our app. Vertical
0:49slicing would mean we split the app down
0:52by feature. So we would first of all
0:54build feature the the off feature for
0:56example. We would then move on to the
0:58note taking feature. then move on to the
1:01account feature. So we in the end take a
1:04look at the whole project and then say,
1:06"Okay, we first of all work on this
1:08feature, then on this feature, then on
1:09this feature." This is one way of
1:11slicing. Another way of slicing is
1:13horizontal slicing, where we in the end
1:15work on the app layer by layer. So here
1:18for example, we say, "Hey, we first of
1:20all build the entire UI for the entire
1:23app, for all features,
1:25then we work on the entire domain layer
1:27for all features of the app, and then on
1:28all the data layer on the data
1:30infrastructure for the entire app.
1:31That's also another alternative approach
1:33of actually slicing down such an app. So
1:35what is actually the right way now?
1:37Whatever you are doing, the very first
1:40thing for you to build is always the
1:42shared infrastructure. So the shared
1:44infrastructure usually also consists of
1:47multiple layers. That's at least the
1:48architecture that I stick stick to that
1:50I will also I'm sure you a practical
1:52example for a moment. But in the end,
1:54you have some kind of shared
1:55infrastructure, something common,
1:57something that all features need. For
1:59example, this could be some kind of
2:02error handling utility, or some kind of
2:04utility that you just need across the
2:06project. This
2:07could be some design system components,
2:09or very fundamental UI components like
2:12certain customized buttons or so that
2:15that multiple features need, some
2:17customized text fields or components.
2:20This could be UI related utility. For
2:22the for the data layer here of the
2:24shared infrastructure, this could be
2:25networking utility, so some kind of
2:28shared infrastructure,
2:30some shared networking utility that just
2:32all the different parts of the project
2:33may access. This could also be a
2:35database instance that the entire app
2:36needs to access and read data from. But
2:39since this is something that possibly
2:40all or at least multiple features need
2:42to access, that is what we need to work
2:44on first. Because without the shared
2:46infrastructure, we wouldn't be able to
2:48finish a single feature in the first
2:49place if that single feature needs the
2:51shared infrastructure. And specifically
2:53to this layering here, the UI, domain,
2:55data, you always want to start with the
2:57domain layer since that is the innermost
2:59layer according to this architecture.
3:02This is the layer that both UI and data
3:04will access, that both UI and data will
3:08have dependencies towards, not the other
3:09way around. Domain should be very very
3:12isolated in the middle of your onion
3:14kind of. That's how the clean
3:15architecture diagrams typically show
3:16this. And here it's actually the same
3:18concept within this little boxy for the
3:21shared infrastructure. So on an app
3:23level, we want to work on the shared
3:24infrastructure as a whole as a first
3:26thing because multiple parts of this app
3:28need to access that.
3:30But
3:31when taking a look at the shared
3:32infrastruc- infrastructure specifically,
3:34we again want to slice this down. So
3:37this shared infrastructure is
3:38technically one slice, but we want to
3:40further slice it down, and then work on
3:42the shared infrastructure for the shared
3:45infrastructure first. Because the domain
3:47layer is in the end the common stuff for
3:50the shared UI part and for the shared
3:53data part, because both UI and data will
3:55have a dependency to domain. And that
3:57means we need to work on domain first,
3:59because no matter if we go on with UI or
4:01data, they will both need this
4:02dependency on domain. They will both
4:04need the models that domain defines.
4:06They will both need the business logic
4:08that domain defines. So, it only makes
4:10sense to start working on domain, then
4:12on UI, like as a second step,
4:14technically you could also work on data,
4:15because UI has nothing to do with data,
4:18so
4:18what whatever you start with technically
4:20doesn't matter. But, here comes the
4:22thing.
4:22Go on with the UI, go on with working on
4:25that, because UI is something that
4:26instantly gives you something visual,
4:28something you can see. If you work on
4:30data as a second thing, it's quite hard
4:33to actually
4:34verify whether what you've built
4:36actually works. Um because you would
4:38technically have to do this with test
4:39cases, with some print line logs, but
4:42the data layer is something you can't
4:43actually just Well, you can't launch
4:46something and just click around, because
4:47well, you don't have a UI yet. Or you
4:49would have to build a dummy UI, and then
4:50you have something that you will have to
4:52delete later again. So, the easier
4:54approach is simply to to go on with the
4:56UI layer,
4:57because it's much easier to actually
4:59build some something visual you can see
5:01in the previews, what you're actually
5:02building, and that's all you need in
5:04order to verify the correctness of your
5:05UI layer. And if you then go on with the
5:08data layer as a third step, and you
5:10actually implement your DB, you
5:12implement your API access, then you can
5:14instantly verify that now, because you
5:17have the UI already that connects to it.
5:19You can instantly launch the app, and
5:21you can simply click a button that
5:22triggers a network call, and you can
5:23really see if that network call is
5:25working, if your list, for example, is
5:27populated with data. But, you can't do
5:29that if you start with data and then go
5:31on with UI.
5:32But, so far we are still at the shared
5:34infrastructure. We still haven't yet
5:35talked about any real features.
5:38So, what we want is
5:39we want to take a look at all the
5:41features here. So, this is in the end
5:42again our entire app with all the
5:44features, excluding the shared
5:46infrastructure, what we see here on the
5:47right. And all these features, or
5:49multiple of them, can at least access
5:51the shared infrastructure now.
5:53So, what we want is we want to first of
5:55all vertically slice our app
5:58into distinct features after having
6:01worked on the shared infrastructure. So,
6:03we of course want to determine which
6:04features we have. We then want to work
6:06on the shared infrastructure, and then
6:07we want to vertically slice the app
6:09feature by feature, work on the app
6:11feature by feature. But, each feature is
6:15then horizontally sliced. And each
6:17feature, we again slice that down, and
6:20we just don't approach the feature as a
6:21whole, but we say, "Okay, for a given
6:24feature, we again have a domain layer
6:26that we work on first. We again have a
6:28UI layer that we work on second. We
6:30again have a data layer that we work on
6:32last." Just for the UI, domain, and data
6:36related code for this feature that we
6:38only need inside that feature, plus what
6:41it may get from the shared
6:42infrastructure. And this is then how we
6:44really go on working on our So, for
6:46feature B, uh that is then in the end
6:48what we would work on after having fully
6:49implemented feature A here as fourth,
6:52fifth, and sixth, and so on. So, we
6:54really just build everything here in
6:56this exact order. And this is still
6:58quite abstract, I know, and that is why
7:00I will give you a practical example
7:03right here. So, this is in the end
7:04Shuff, that's the app that you learn to
7:06build in my Kotlin full-stack developer
7:09bundle. You'll find the link below. Uh
7:10but, in the end, yeah, free course
7:13bundle about building a Kotlin
7:15multiplatform app. And here I'm applying
7:17exactly that kind of slicing that I've
7:19just shown. By in the end having a
7:23module. So, this is now something that's
7:25of course dependent on the exact
7:26environment you work on. Here in Kotlin
7:28multiplatform and in native Android
7:29development each layer in this case and
7:32each feature would be its own Gradle
7:34module. So, for example, we have an auth
7:36feature consists of all three layers,
7:38well, in this case only two layers
7:39because there is no
7:41nothing about data that would be
7:43specific just to off that does not come
7:45from the shared infrastructure. But we
7:47in the end have one such module per
7:48feature. So for off, in this case it's a
7:50chat related app.
7:52We have a chat module and here also
7:54these three layers which we approach in
7:56exactly that order that I've just
7:57mentioned.
7:58For the shared infrastructure, we
8:00actually Where is that?
8:04We actually here have our core module.
8:07So core is typically how we call this
8:09when we have some shared infrastructure,
8:11some classes, functions, etc.
8:14that in the end all our features can
8:16access.
8:17And you can see we have data, domain,
8:19presentation here again. That's exactly
8:21what I've shown you here also for the
8:22shared infrastructure.
8:24In my case, I'm additionally working
8:25with a design system module.
8:27So I'm further just splitting down
8:30the UI layer kind of for our shared
8:32infrastructure into design system
8:34components so really just reusable UI
8:36components and into just presentation
8:39where the utility that is not about
8:41anything visual in this case, about any
8:43composables. So about rendering real UI
8:45components. But with these greater
8:47modules, you can then really just define
8:49exactly which kinds of dependencies you
8:51want to have. So this would be the other
8:53part. I don't want to dive too deep here
8:54into this
8:55the actual architecture behind, but much
8:57more about how you split down such an
8:59app in the first place. For a real
9:01architectural deep dive, I'd rather take
9:02a look at our mentorship program in the
9:04video's description. But all in all,
9:05this is how this could look like in the
9:07real world. I also want to share exactly
9:09why I have this split and not the the
9:13other module split where we could of
9:14course also have a presentation, domain,
9:16and data modules at the very root of our
9:18project. But you can see here at the
9:20root of the project I have a feature
9:22module with a single module per feature
9:25and then each feature is split down into
9:27clear layers. But we could of course
9:29also say that we have a presentation,
9:30domain, and data module at the root and
9:33inside these we just put the entire
9:35app's UI code in the presentation
9:37module, the entire apps data code inside
9:39the root data module, but that's a very
9:42bad approach. The approach that I have
9:44here has multiple advantages. In the
9:46end, we keep the features very isolated
9:48because one of the reasons we may want
9:49to have a multi-module architecture here
9:51is uh just reusability of certain
9:53modules.
9:54If we keep a feature isolated, and maybe
9:56an auth feature, then we can completely
9:58reuse the entire auth feature in another
10:01app that may need this exact same
10:02authentication mechanism. Also, if we
10:05would have root modules called
10:06presentation, data, domain, and we
10:08include the entire apps code in here,
10:10then that would obviously really be
10:12bloated. There would be a lot of code in
10:15those root modules. They would grow
10:16infinitely. If the app grows, these
10:18modules will grow, and that kind of
10:20defeats the purpose of having modules in
10:22the first place because one of the
10:23reasons we have that is also to speed up
10:25our Gradle build. And if these modules,
10:27so maybe only three or four modules we
10:29have for the entire app just keep on
10:31growing, then it will not only become an
10:33unmaintainable mess, but the Gradle
10:35builds will be slower and slower and
10:36slower the larger the project gets.
10:38If you're working in a team, this
10:40approach here also has the advantage
10:42that different team members can actually
10:44work on different parts of the project
10:46completely in isolation without them
10:48interfering each other, without teammate
10:50A accidentally changing code teammate B
10:52has written yesterday.
10:54That shouldn't be changed in the first
10:55place. But if you actually say, "Um
10:57Peter, you work on the chat feature."
11:00then this this architecture is making
11:02sure
11:03that these features are built in
11:04isolation.
11:05That this chat feature's data layer
11:07knows nothing about the auth feature's
11:10domain or presentation layer. And even
11:12the chat feature's presentation layer
11:13does not know anything about auth
11:15presentation. So, the architecture is
11:17intentionally built in a way that the
11:19features are completely isolated, and
11:20the only common ground is what we have
11:22in core. That is the only thing that
11:25features are able to access. And
11:27obviously, Gradle build speeds will be a
11:29lot faster with this approach since
11:31Gradle can just paralyze certain builds
11:33here when multiple changes are being
11:35made in isolated feature modules, then
11:38all these modules can really be built in
11:40parallel. You really benefit from faster
11:42builds there, especially for large
11:43projects. So, all in all, this is what
11:45has been my preferred architecture for
11:47the past 4 years or so. Those of you who
11:50got my courses will know this. I'm still
11:52sticking to this. This has never
11:53backfired for me. This has always
11:55worked. Get into it. Learn it.
11:57But, this is in the end how I slice down
11:59my
12:00So, as a summary again, first of all,
12:02you want to have vertical slices. You
12:03want to think about which features does
12:05the app consist of? And then, per
12:07feature and the shared infrastructure, I
12:09kind of consider as a feature, as
12:11something we would have to work on
12:12first. Then, per shared infrastructure
12:14or per feature after all, we want to
12:16horizontally slice that. So, by layer,
12:19we first of all work on the domain
12:21layer, then UI, and then data. And if
12:23this is confusing you,
12:25I get that. It's a lot to learn and this
12:27is just something you have to practice.
12:29You have to build yourself in a project.
12:31You have to really understand the ins
12:33and outs of, especially in terms of AI,
12:36where an It's very easy for an agent to
12:38just strongly accelerate on a wrong
12:40foundation for your app. So, if
12:41architecture, system design, the modern
12:44Android tech stack is something you want
12:45to get super super deep into and become
12:48a really desirable Android developer,
12:50and then also learn how you can
12:51accelerate that with AI after having
12:53gained the technical fundamentals. Then,
12:55take a look at our senior app developer
12:57mentoring. We really help you grow to a
12:59senior level, be it as an Android
13:01developer, be it as a Kotlin
13:02multi-platform developer. We will help
13:04you both technically as well as on the
13:06AI side to then really speed up
13:08everything. Link is below. Take a look
13:10at it. Apply. And then, we're going to
13:12have a chat very soon. Thanks for
13:13watching. I will see you back in the
13:15next video. Have an amazing rest of your
13:16week. Bye-bye.
13:22>> [music]
13:25>> Mhm.
13:28>> [music]
13:29>> Mhm.
13:31Mhm.
13:33Mhm.

About this transcript

This page contains the full transcript of Vertical vs. Horizontal Slicing - The ONLY Right Way to Split Down Your App by Philipp Lackner, generated from the public captions YouTube serves with the video. The transcript has 2,710 words across 415 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.