Strategic Domain-Driven Design by Manfred Steyer

cool Malviya talking so thanks for this nice welcome and thanks for being here and having me this talk is about architecture and Sun and I want to start with a question have you ever wondered what it takes for a real good architecture a sustainable one a maintainable bond architecture you can live with for the next I'd say 20 years well in my opinion it takes a lot of experience experience of a diverse group of people where everyone can bring in their lessons learned and of course there are some ways to accelerate the creation of the good architecture for instance you could go with caffeine or of course with pizza when it comes to pizza I'm very recommending pizza Provence Yala perhaps you know Pizza Provence yalla it's the pizza with corn and with bacon and ham on it I only made good experiences with it especially in the area of architecture but then they stick to experience a big question is how can be moved experience from one hat to another hat and to answer this question a lot of people have written down best practices and some people try to formalize this they have written down balanced design patterns architectural patterns something like this and then some people took a lot of patterns they took a lot of best practices they added a bit of philosophy and so they are ended up with the whole methodology and design domain driven design is one of those methodologies a methodology that helps you to create a nice architecture that addresses all your requirements and to be honest domain driven design has been around for quite a while it has been around for about 20 years but nevertheless it contains some things that might come in handy for your front-end architecture and this is what this talk is about in this talk I will show you how you can improve your front-end architecture by using some ideas of domain driven design and this is the important thing for me it's about ideas from domain driven design for me2 main turbine design is not a religion it is just a methodology that has some things that can come in handy saying this regarding the contents of this talk we will start with strategic design which is one part of domain driven design if you ask me the most important one then we will look at the same coin but from another perspective we look at the other side of the coin from then technically perspective and for this I will talk about mana ripples and then we will try to take those two parts that matter the lock to key parts the technically part and to combine them using an axe and mono repos depending upon an axe at the end of the day I will give you a show a demonstration that shows everything in context but first of all let me introduce myself I am unthreat I'm a trainer and consultant for Angola nowadays I'm helping a lot of companies with angle a trainings with Angola consultancy and I'm also part of the Google developer expert team I'm quite proud of this since the beginning of this year I'm also part of the Angola team there I am a trusted collaborator I have helped to implement some new features for the CLI aid for instance I have helped with differential loading I'm doing a lot of stuff in Austria and Germany and if I'm behaving well then I'm sometimes allowed to enter other countries like yours here my current product is also about Angola it's a workshop regarding Angola in the enterprise we are doing this workshop in some cities and more often we are doing this workshop in some country in some company as an announcement ok so let's get started with the first topic let's get started with strategic design so if we look at the main driven design this methodology I've told you about you have to pick disciplines and one discipline is strategic design the other one is tactical design and strategic design is all about decomposing a pick system into tiny aparts that means you don't want to have this huge system that can do everything instead of this you want to have several tinier systems that are less complex technically design is mostly about design patterns and practices here I will stick with strategic design because as you can imagine this influence is your architecture most and if you would ask me to show you just one slide that explains what strategic design is about I would say it's prevents this situation here this very situation where you have a big system where everything is in the mingled with everything else of course something like this is not sustainable something like this is not maintainable let me give you an example then I've prepared for this presentation one system came in mind namely an e procurement system that allows employees to order some stuff for instance sheet of paper or a pencil or perhaps a new laptop by the way this was the first software system I was fully responsible for it was about 20 years ago and you know your first project is like your first big love you will never forget it it will always be somehow in your mind and if you would write something like this you would not write this pick Gamzee e procurement system you would write several tiny systems instead for instance a catalog system or an approval system where the manager can say yes or no or an ordering system that sends out the orders or in our case we had a specification system where an expert has done a fine specification for your requirements for instance you say it as an employee I need a new laptop and the experts said oh you are a power you so you get this laptop or oh you are not the power user you gets this let's say tablet or this big laptop a very nice example back then we had in our documents was perhaps someone is requesting a CD burner you see it has been a long time and the CD burner was back then an object of prestige and not everyone is allowed to have a city burn that the people say it's there and so the specification folks have to decide upon whether this person deserves the city burner or not from the example if you ask me well you will decompose your whole pic system into tiny aparts and those parts are called subdomains and this is really the hardest part of it finding good subdomains one interesting thing about subdomains is that each and every sub domain can have the same entities but they can have a slightly different meaning just look at my catalog system and at my approval system both has a product but a product itself has a completely different meaning their product in the catalog is a big thing because the whole catalog is about products it contains not only a title and a description it contains a range of rises repet ranges and so on discount ranges it contains a lot of pictures and q and A's when it comes to approval pictures prices q and A's are not that interesting for the manager the selected price is interesting the selected title and of course the budget that is used to pay for this product so as you see here you have the same names but behind those names you have completely different concepts and when it comes to the main driven design you not even try to unify those concepts because if you try to unify those concepts you have this big product entity that is connected to everything in system and so you will end up with a not good architecture where everything is in diminished with everything else so there is one term you will probably see when you look into domain driven design it's the pound that context normally each and every subsystem each and every sub domain has a bound that context and this bound that context defines the boundaries with in your model is meaningful your model is not meaningful without this context it just have a specific meaning within it within this context we have this general language this general language everyone should use this chain or language that should mirror their domain that means you will not invent new terms as a developer you will just use the terms that are used in the domain to mirror it to make it more maintainable and to make it more useful for the domain experts the users so if you are ending up with several sub domains you will quickly find out that those sub domains have to communicate with Aurra for instance the specification sub domain needs some product data from the catalog and so does the approval domain and so does the ordering domain and of course you could say hey everyone is allowed to access the catalog but this would not be a nice step because if the catalog changes you have breaking changes everywhere else so it is not a good idea to give everyone full access to a domain one thing that might be a bit better it's still not the best solution but it's a next step towards a better solution is using a shared kernel which is just a shared library which is used by each and every domain the owners of those domains can put the common things into those shared cradle and everyone is responsible for it and you know and this is the drawback if everyone is responsible for something at the end of the day no one is responsible for it and you will have breaking changes if you don't take care and if people don't look at all the changes very closely another strategy that could come in handy is just providing an API which means that you have your domain and you are just providing a tiny API and everyone else is only allowed to access this API this components this part of your state these services everything else is hidden behind the API which means that everything else can be changed by you but if you change something that effects the API you have to be sure to be backwards compatible do not create breaking changes for other domains the official term here is not API the official term here is open or host service I'm just calling it API because API fits better in this tiny black box here ok and when you look at domain driven design you will find a lot of additional ideas for inter domain communication so this was the first part of the coin it was the methodological part of the coin now let's move to the technical side of the coin which is about mono repositories a moaner repository is a trap - simple thing it is just a big project that contains a lot of sub projects you can compose your pic application into tiny amour or less self-contained parts and all those parts go perhaps here in this project folder and this is several advantages one that Vantage is this node modules folder here not that it exists but that it exists just once that means that all your sub projects are using the same version of angular the same version of our ex and this is probably a nice thing because just imagine you would use angle of 5 fear and angle of 7 there and then you try to compile everything together I guarantee you all hell boots break loose this is prevented by the structure and other advantages sharing your libraries is not difficult just check it in in the source control and your colleagues will check it out from source control and get a state a bunch of libraries that can work together that have been tested together so creating a workspace is quite easy nowadays you can leverage the CLI perhaps you have seen this you install the CLI you new up a new workspace and then you can generate an application within the CLI or a library of course you can also generate further applications or further libraries then you can surf your application and then you can build your library or either your application just by pointing to the name of your piece of code so this is really quite straightforward if you love this idea with decomposing a pic system into tiny aparts if you love this idea of Molnar APIs I would look into NX and access what I'm calling the sugar tip on top of the angular CLI it enhances the CLI by some features that are very in handy when it comes to mono repositories just let me show you one of those features one of those features is you can easily visualize which libraries you have visualized which applications you have and visualize which part of the system is accessing which other BOTS and this is very vital in big business software systems because normally you want to avoid that every part is accessing every other but in this case you would have a highly coupled system that is not maintainable here we are seeing via codes not everything is in the main lead everything is perhaps using this common validation library but this is occasion ok now we have seen do things there methodology domain driven design strategic design decomposing your system into tiny aparts and we have seen that technically story which is about mono rebels now let's bring everything together let's talk about how we can combine this idea of strategic design with an axe based mono rebels and if I would do this first of all I would just create folders for all my domains here I'm just seeking with two domains for the sake of the tiny screen of course I would also at the shared crandall at official shared domain which contains the shared Crandall and other shi'ites Technic libraries and then within those folders I would start with creating libraries layers of libraries the first layer is what I'm calling the feature layer the feature layer contains libraries we feature modules every feature module contains just one feature one use case like order a product or approve a product so you would end up with several feature libraries here then the next layer of libraries is a layer of UI libraries they contain tamp components components that are not aware of features components that are not aware of use cases but components that can help to implement them just think about a date time picker the date/time picker is not interested into the use case it is used in it is just there and so it can be used across several use cases across several features or think about an address component many business products have this addressed components that issuers that address looks the same in each and every use case the next layer contains your domain logic which is about validation logic which is about calculations and then you have utilities with general stuff you need a verb when you are doing this when you are introducing layers you can easily introduce a rule this rule is called relaxed layering relaxed layering means that each and every layer is only allowed to access the layers below in this situation this means features are allowed to use the UI the domain utils the domain is only allowed to use the UT layer the UT layer is not allowed to use anything this prevents cycles for instance just think about a situation where everything is allowed to access everything you would end up with cycles and perhaps you know it typescript is not that amused about cyclic dependencies in addition it's also not good for a system you want to maintain you want to reason about because you know when everything is intermediate we've talked about this well every rule has an exception and the exception here is that the UI layer is not allowed to use the domain layer because UI components are dumped components they shall not know the use case that a time picker is not interested in to use case so this is the first kind of access restrictions that helps you to prevent cyclists that helps you to have a proper structure the second restrictions are about domains here you would say each and every domain is only allowed to access things with its own domain and within the shared crown catalog can only access the catalog and shared ordering can only access ordering and share of course also here we need exception for this rule as we have seen before sometimes one domain needs access to another domain for instance as you have seen the ordering domain needs the products of the catalog and this is where our API comes in our API which is just a library that exports specific selected things for other domains and as mentioned only those things need to be backwards compatible the rest can change so one thing that's also vital here is you should try to isolate your domain which means the domain layer is isolated by an so called application layer which is the official term in domain driven design and an infrastructure layer let me give you some terms of the world of angular that explained this those two layers the application layer is about use case specific facades and if you have followed the topic of state management in the last month you have seen that people like to create facades that sit in front of their store facades that provide everything you need for a use case and the infrastructure layer of course is about things like data access or accessing browser API is like the geolocation API like indexdb this you want in general to abstract away you can substructure your domain library or you could also create several libraries for those aspects it's up to you but the point here is isolate your to me perhaps you are wondering why I'm creating that tiny libraries you have seen each and every future module has its own library and creating tiny libraries has several advantages one advantages a tiny library can be the unit of recompilation you do not wants to recompile everything all the time you just want to recompile the changed things the same holds true for testing it can be the unit of testing and it's the unit for access restrictions to prevent cycles to give you a meaningful architecture it's also about information hiding because each of those fine-grained libraries can have secrets they don't need to expose everything to the user or to other libraries and it can be a future replacement for ng modules perhaps you've heard it the angular team is not that amused about ng modules they need it but they don't like it and they are currently investigating ways to make energy modules optional and if they become optional you could use libraries with barrels and so on instead of those modules you could use things that are directly baked into a comma script instead okay let me show you and demonstrate for this in this demonstration I've brought a mono repository it's based upon an axe and this repository has a lips folder and oh you see nothing okay sorry now via talking thank you you see this mono repository with ellipse folder and SEC here this libraries folder has once apfel the power each sub domain there is a catalog folder there is the ordering folder there is a shared folder for the shitcan let's drill into it for instance let's drill into the catalogue domain here we have our libraries of all the layers and what I'm doing here and this is also one of the best practices the nice people behind an X wrote down every application every library has a prefix where the prefix is the name of the layer so I can clearly see okay those two parts belong to the feature layer or this part here belongs to the domain layer if you look into your domain layer you have a lot of generated files and this index TS and I'm always saying this index TS is reason enough to define libraries to define a lot of libraries because this indexed is is some kind of fuss aids some kind of peril some kind of public API it exposes everything the other libraries can use everything that is not exposed here is hidden and as mentioned before can be changed all the time let's have a look at the feature here is a feature browse products with a feature module as you see here and as you see of course the future module browse products is using the catalogue domain it is importing the entry module of the catalog domain and for this I'm using map names this is quite pretty I am not using something like dot dot slash dot dot slash dot slash dot dot slash projects I'm just using a map name which helps me to stay sane on the other side it's also a nice thing because that means I can move my libraries around my code is not aware of the location of those libraries and if you wondering where their resolution of those name is you will find it in your TS config and and axis taking care about this and x is taking care about this it is just writing those mappings here that tells the compiler that eprocurement catalog domain points to the facade to the index TS of this very library okay this is nice so far apart it can get even nicer let's for instance show the dependency graph it is just an NPM script that comes with an X and here it is my dependency graph and now as in every good romantic movie I'm saying one sentence namely let us do something crazy let us start H I'm doing this for a specific purpose H has this nice presentation feature where I can take a pencil here and mark my domains so when you look at the structure here then you see my domains for instance you see hey there is a shell of the catalog domain there is a feature of the catalog domain there is another feature belonging we do the catalog term and there is my domain layer nice isn't it there is also another domain for instance my ordering domain with the ordering shell with ordering feature and so on by the way the catalog API is also part of my catalog domain it exposes stuff for other domains and then there is shared stuff the UI at rest library is part of mesh it kernel as well as the util authentication library and so you can see at first sight yes I have several domains here and they are not in the mingling with each other there is a way to access parts of those domains and this way is really defined it is well defined I can access the API or the shotgun and now let's do something that's very bad let's do something like this let's access and uipath from our UT layer normally a UT layer is not allowed to access UI paths because you're out indication logic should not directly use some component it is just a logic and it is also against my layering rules when you are remembering this matrix I have showed you before utils have been on the bottom of this matrix and you I have been somewhere above it so let's try to do this for this I'm switching to my Oh for this I'm switching to my shared module and here I have prepared some pet code and you see immediately boom approach act act with util can only depend on libraries with nothing which means in good English aut layer is not allowed to use any other layer to prevent cycles you can have restrictions like this all the way for all the things I've shown you before it is cha the matter of lending you can configure your an axe based mono repo with linking roles that take care approach this the best thing about this is you can also run this linting stuff on the command line I guess you know it and she'll int project util shared out and then we should get the same slap into our face we are not allowed to use this library from the utility layer and now if you think one step further perhaps you are still doing this you could introduce this into your source control system and so perhaps the source control system does not even allow you to check something like this in to check code in that drives across there one way okay so let me sum up what have we seen today we have seen that it is probably a good idea to slice your application in subdomains in tiny self-contained subdomains to prevent this in the mingotts situation this is also what I'm calling the article slicing and then you should slice the whole things into layers this is what I'm calling horizontal slicing and you should use something like layering could be strict layering or non strict layering which is also called relaxed layering we are just each layer is only allowed to access the layers below it you should go be fine-grained libraries because the library can be the unit of recompilation the unit of retesting and the unit for access restrictions saying this enforce restrictions so that not everything is in the main gate with everything else and there is a last thing I want you to remember if you forget everything please always remember this one tiny aspect it's very vital for me namely when doing architecture caffeine and pizza can as the whole process and as mentioned before I'm recommending their pizza provincia you know ham bacon and so on okay so thanks for coming you find my coordinates here you also find all my material on my block and here you have also some further informations about my workshop so thanks for coming and if you want follow me on Twitter so that we can stay in contact thank you [Applause]

Channel: ngVikings

Views: 2,081

Rating: 5 out of 5

Keywords:

Id: 94HFD391zkE

Length: 31min 44sec (1904 seconds)

Published: Wed Jun 05 2019