 Next up the repository style. The repository is a style in which you have a central component in the middle which we'll call the repository and you have a number of components that access this repository that are around it. So it's kind of a star-shaped architecture and well the feature is essentially that the data and similar operations that you might need on the data are in the middle and then you have a number of components that access this data but they are completely independent so they do not have any dependencies between them. They don't talk to each other and a common application in which you have this pattern is for example an IDE, a development environment, so imagine for example a code editor like VS code. The code, the files, the repository that you access, like a Git repository, they are in the middle and different components of the IDE are accessing and working on this code. So for example you might have the actual text editor, you might have another editor, for example maybe there's a depending on your tool it might be that you can also do UML drawing if we have something like Eclipse for example. You could be doing that. You might have a certain analysis tool for example and a linter that works on the code and checks whether the stylus is correct whether any bad smells and you might have other things for example let's say you have some kind of report generation for example test coverage or comment percentage in the code and all of these are independent so they just access the repository in the middle and well the obvious advantage here is that these components here don't have interfaces so they don't need to talk to each other if you for example have a team that writes a linter and a team that writes the text editor they don't need to communicate, they don't need to check whether everything is aligned whether their dependencies are correct or not. However that's also at the same time a disadvantage because everyone has to talk to the central repository so this central repository has to have a lot of different interfaces or a very generic interface that you can use for different things so there's all that access in the middle and obviously depending on your application this can also become a bottleneck because all the calls go to the repository so in terms of performance for example this needs to be very efficient and if you would think of a distributed application so these are actually things that are distributed for example on the internet or a network you also have a single point of failure so if the repository would fail the other components are essentially useless they can't do anything without access to the data so this is why for example you have this in a local application like an editor but this can be trickier if you have a central access so that's the repository pattern again something that is extremely common when you have collaborative work on a central piece a central model or data you will come across this in very many applications. Now the next one we go into is again something you're very familiar with and that's declined server style