Clean Architecture

Everyone. This, is, my, second. Time recording this kind of thing so please bear with me for, any hiccups here, and there. Okay. So. What, we are looking at here is an email from only. He. Asked me Caroline candor to present, a project about, clean, architecture, and. One. Year in six, days letter today. Here, is the dog. Back, this. Presentation, is brought to you by ping, and written, we. Have many lessons about architecture. That we learned during the, development, of casters chat especially, on Android platform, and, we, hope we can share. It with you. All in, this presentation. Let's. Start with the title itself, clean. Architecture. Most. Of you must have known about this, article it's pretty, famous it, was probably, the first time Uncle, Bob coined, the, term playing architecture, and, it was in 2012. Six-year-old, I know but. It was not the first time someone, came across with some name for architecture. Before. Clinton, collector, was hexagonal. Architecture. By alistair cockburn some. People refer to it as spots, and adapters and. There's. Onion. Architecture. By, Jeffrey Palermo, there. Is also TC, i-- and PCE and, then. Finally, a kebab. Came out with two an architecture. And. Interestingly. All, of them other they, different, name and fry, in details they, have all the, same characteristics. That is they. Are independent. Of any external agencies, be it frameworks, user, interfaces, for databases, and obviously. It's testable, I will. Not deep dive into each of them in this presentation and for. Simplicity I will only use the diagram of doing architecture from alcohol. Before. We, go even further I first want to clear out any potential, confusion, or code with this, some. Of you should have known about this it's the fire software, architecture, patterns from aurélie. Software, architecture, conferencing, in 2017. They. Have this seven, architecture, patterns. So. How do they differ from the previous, architectures. We're talking about, the. Already. Architectures. Are describing, block. Diagram, well, the previous ones. Hexagonal. Onion, and clean. Describing. Dependency. Diagram, I hope. This flares out any confusion, and we will not be discussing of what or really architecture, patterns here we, will only discuss the. Plan architecture, one. Okay. Let's continue with the stun software. As the name suggests software. Was invented to be soft what, does soft me, somewhere. Is soft means that it should be easy to change because. If, it. Was hard to change we would have called it hot when it, makes sense I'd it's, hard to change the microwave, into a cell phone well. It's possible but it's not however. It, should be easy to change the messaging, app into, a financial. Technology, application, that can send you money so. Every. Time you find yourself thinking that it's hard to change your code maybe you should ask this question, I'm I'm, making a software, or hardware. Now. How, do we make software soft it's, by living as many options open as, possible for. As long as possible it's. Quite remarkable. What. Options are we talking about here it's, the details, that do, not matter. For. Example databases for, your architecture. It should not matter if, you use my sequel, atmospheric. IO. Devices, it. Doesn't, matter whether you use punch, darts or magnetic, tapes or harpies, or, car. Surfers. AWS. GCP. If an on premise it should, not, matter to your application, you should keep your options open. Now. How. Do we keep our options open. The. Answer is actually, pretty simple we. Have heard, it over and over again I'm sure some PF con superport. Hearing this solid, term but. Worry, not my friend I'll do, my best not to be just mater slides but solid also. I will only talk about interface. Segregation principle. And dependency, inversion principle I will, not talk about the first three and you will see why. Dependency. Inversion why. Is it so important let's. Talk about the, simple, copy program. You. Declare, a failure plane and see and then. You get. Down and, put. It until. The end of file. Let's. Take a look on the inset of Kitka, it's. Also pretty, simple, it invokes, the, root, function. From, a pointer, named, standard. Input, stdin. And. What is the, start of input it's a pointer, variable, pointing. To a file, strap, and. It. Was given the address of, console. What. Is console it. Is, an. Implementation, of fan, strap and. It. Has, these, five. Functions.

Open Close red white and sick and. If, you see this, file, through here they have these. Five. Pointer. To functions. Now. The interesting, part is we, can swap. This. Standard. Input with another file, strap implementation. The. Way we read and write the, punch card is different, with that from magnetic tapes or this, or even the. AWS, valve, but. The copy program, is still, same the. Algorithm, is the same it's, the same copy, program, but. With different IO devices. We. Have learned to. Make the reader and the writer. To. Depend, on the. Copy program and not the other way around, so. Why do we bother to make this kind of point of the functions, just, for this simple puppy program, because. We have learned that. We need the same program, the same. Algorithm. To run with different, devices. Be. It punch cards magnetic. Tapes then, floppy disks compact. Is flash, traps and now the clock and. You. See this, source code was. Written in C so. The concept, of dependency, inversion has. Been there since the 1960s. Even, in a non object-oriented, programming language. The. Copy program is a simple. Example to give you the idea of a more abstract, and higher level concept that is dependency, inversion. Every. Program or application. Or, system has this two can of arrows the. Dotted. Green one showing the flow of pondrá or the, flow of data in your system and the, red one showing, the source code dependency, usually. Both of them are pointing in the same direction just. Like this diagram. But. With, dependency. Inversion principle we. Can infer. The. Red arrow the, dependency, at Oh every. Time we want and everywhere. We need it and we can. Do it thanks to the power of polymorphism. In. Java Java, problem which you will use interface. Or absolute, mastery. Just. Like how, we make. The reader and writer. In this. Case the console console, reader and writer depend. On the copy program here. But. It's written in C C. That's a net interface, oh yes, that's correct, C, doesn't have interface. This. File struct is the, interface, this. Point, of the functions, are the, interface and it's. The beauty of it the concept, of dependency, inversion does. Not only apply to modern programming, language, and certainly. Not only for object-oriented ones it's, universal. Now. Okay, we can invert the dependency, direction every time we want but, what are the benefits why. Do we want to do it for. The copy program we, have seen the benefit we don't need to record, copy program it's time we have new IO devices, so. What's the abstraction of this what's, the higher-level benefits. With. Dependency, inversion principle. Suddenly. You, can develop your business rules. Independent. Of any user interface. Independent. Of any databases. Remember. UI. And databases. Are details. That do, not matter. This. Business, rules here are the, ones that matter and if. You can develop it independently. Then. You can also deploy. It independently. And guess. What the. Concept, of independent, developer ability has also been there since the 1960's in, the Apple spacecraft, design it says. Minimize. Functional, interfaces, between, complex, pieces of hardware in. This way two, organizations. Can work on their own hardware relatively. Independently, and, that. Is dependent, independent developer, ability, it's, been there since the, since, nineteen sixties can, you imagine if the, independent if, the. Dependency, inversion principle can. Be applied on, hardware there's, no reason we cannot apply it on any programming, languages. Okay. That's dependency. Inversion that. Suits to another topic library. Versus Redbook don't worry still a directed, so. What's the difference between library, versus framework, to. Be able to answer that let's observe some, snippets, some code snippets, observe. The C++, program, it, includes. The iostream, library, and string. Library and, it. Prints the hello world what's your name and then it will wait for users, input and then, it will print out your, your. Name is blah blah blah. Then. Observe, this PHP, code it's, using. Werfel framework user. Controller a sense controller. There. Is this method show and then we define route, to this.

Controller. Java. Program which using, android, framework just, fragment. Access webmin and then we offer at this many, method. Same. Thing with Swift expanding. UN official notification controller, and we offered some methods. Java's. Java spring a little, bit different we use this annotation. At control, on it and get, mapping and. There. Is also this ESX. ACMA. Script six source. Code using react framework. Clock. Extends, reactor component, and then we. Kind. Of off right. These methods. So. What's. The difference what's the relationship within your code library and framework this, diagram, nicely. Some rest at all unfortunately, I cannot find the original creator. Of this diagram so I cannot give proper at the question. Your. Framework. Calls. You, cause. Your code your. Code cause the library and sometimes, framework, contains library. Now. This. Is a problem with definition. If. We. Refer to this diagram it should be obvious that react, is a framework, because. The. Reactron work will call this method. We. Do not call this method. Ourselves. But it will be called by a framework, but. The official, website. Of. React.js. Clearly. States that it's. A JavaScript. Library, so. We are not gonna discuss about that in this presentation I will leave it up to you whether eating react is a framework or library. So. In, a few words the defining, characteristic, of a framework is this. Inversion. Of control the. Framework, calls you and not the other way around from. Inferential control the, term a false to become dependency. Injections, you, can check about it more on this article by martin fowler. Okay. That's a lots of theory, it's, now time to share with you about associate, implementation, and i'd. Like to remind you that the implementation might not be as idealistic. As the, theories, when. We go from. The Oriental implementation. Sometimes, we have to be practical we have to be serviced. This. Is a, picture, to give you an idea but Castro said under a dependency. Diagram before. And after we, grasp the, concept of lien architecture, as you can see it looks like spaghetti. Code circular. Dependencies, here and there, now. Since. The, very first beginning we have been using the boilerplate, code from, hundred. Ten github. It's. Unwritten. Architecture, boilerplate. Code and, there. Are these two, pictures. In the github. Office. If we. Perceive. This diagram, this diagram, and. Of everyone as it. Is a WC. Diagram which, arrow do, you think is the correct one is, it a or. B. Just. By looking at the wire names so it's presentation. Domain, and data which one is the correct mm. C direction. If. You, haven't decided on the answer yet you might want to post clear because the correct, answer is B it's, the pillow line, the. Boilerplate code, from underwritten was inspired, by Uncle Bob's diagram. Of train architecture, so it. Should be safe to use it if we use it we will definitely confirm. With clean architecture, right right. Well. Turn. Out it's wrong we. Learn. That. It's, really dangerous to, use something that you don't really understand, yes. This. Is the first iteration, of our dependency, diagram the. Left, one is the diagram, with thing we, have. Presentation. Depends, on domain and domain, depends on data. The. Setting, is that it's, wrong and even. Sadder the reality, is even, worse our dependency. Diagram on the first iteration is actually was actually, looking look, like this right man. It's, circle represents every, where. This. Is the correct, dependency. Diagram that is also our second iteration the. Domain. Is like. The business shows presentation. And. Data. Is like the UI and databases. It seemed, them to this, diagram we've seen before the, dependency, arrow should point inward into, the, business, strokes and. This is a more complete, highlife, a few of our dependency. Diagram compared. To plane, architecture, diagram from Mankato from. The innermost, layer, we. Put in Titus, and use cases into. One module there is domain, Moodle and then. The presentation. And data both belong in the same layer the, screen, layer and, finally the uttermost, layer.

There. Is the details, that to not matter under. The truck man, our, I'm, life library, and smack framework all of them are on the outermost layer theory, the blue one and. All of them point, in, word. Domain. Doesn't, know anything, about presentation. And data and. Cascading. Lee it also doesn't care about Andres. Fragments, or omelet or spectrum, block. Previously. We know that there are two benefits of using, cone architectures, those, are independent, employability. And, if co-op ability I'd. Like to add one more benefit. Using. Clean architecture, we will be able to easily swap. Or upgrade, our third party dependencies. This. Is one real example, in. Puskás, check we treat smack, smack. Framework as it did a detail that doesn't matter we, put it on the, outermost layer on our. Domain, Moodle, or you, can say domain layer we, have this scripture, interface, it contains, the contract, related to groups how to create, joy, and exit group etc and. Then, on the data. Layer we implement, the contract. Using. A smack, library, pay. Attention to the importance, here on domain. Layer it only. It's. Only six, lines well. In, data, layer it's 35, lines it. Makes sense our domain. Layer doesn't, need to know about the details where our data. Is where already the, details are implemented. The. Trust, from smek framework that we used to implement group chat is this one, smack. X dot M you see that multi-user chain and it's, only imported, in just, a few class in fact in this case it's only in one class this smack group chat class. Then. One day smack, decided, to upgrade its, ration from four, one, six two. Four one eight, and it, contains, frigging, changes the. Way it reads group is now different so we have to change the implementation. Had. We not use dependency, inversion principle the. Multi-user, chap usage would have been everywhere and it, surely will take much longer time to upgrade it I, don't. Wait to view it is like. This way let's. Say we deploy our system, using cloud in AWS. And then. A cheaper, alternative comes. Up there, is Google cloud platform GCP. We, should be able to swap our deployment, system to TCP without, touching our, business, rules because, no matter where we deploy our system, our business, rules stay the same. Okay. Let's move on again to the next topic about, flow control, how, its, components. Communicate with each other, and. It's talking. About this little, diagram. On the bottom right corner of clean architectural diagram. So. About. The use case interrupter. We have, this, abstract. Class name, use case it's, a template, class you have input an output and. We. Have abstract. Method we'll discus, flowable, and we. Have public, method, execute, here it receives, two parameters. The. First one is subscriber, and this. Is, a. Interface. This is an interface from. Another. Library rx Java and, about. Our Java it's a whole another discussion for. Now we only, need to know that it's an interface, and. This. Subscriber, will be our output, part so. This one. And. The. Second. Parameter. Is the input and. Then. We, have, we. Extend, that, up. Stroke us this case into. The implementation. Detail, for. Example this one is a lot more messages. Case and, we. Have this, distinct. Buddhist get. Message param it's it's. A class this will be our input port. We. Also implement, the, abstract. Method from before the put your skis float. And the. Inside. Of this is our unique algorithm, and then. We have, this presenter. Class just presenter, pay. Attention to this method. A lot more miss. It. Inside. Of it we execute, the use, case the a lot more message use case and for. The first, parameter we. Implement, the subscriber. Interface, here from, before and, we expect, the output to be, lists, of messages, and if.

You Look closely the arrow arrow. Here is pointing, to T arrow. Between, presenter. And use, case output port so it it means see this is the implementation, of this, use. Case octopod, and, then. We in for, the second parameter we, instance it is get. Missus, forum. And our. Input. Port and finally, we. Have this fragment. Class I, remember, it's it's. Under specific it's in the outermost layer and, if. You look closely we, inject, the, chat, presenter, here that means, we also inject, all subsequent, dependencies. On chat presenter, which. Includes a lot more messages case obviously, also. We have this chat, view is, awfully, obviously. In our interface that. Is implemented. By this chat fragment class and. The, chat view interface. Itself. Is used in Chapter Center, we. Need this interface. Unit is jeffrey interface to infer, the, dependency. So it will be checked. When that depends. On the jet, presenter, and not the other way around and. So, our flow, of control begins here you. Can think of this chat fragment is our controller. This, green. Rectangle. Here. The. User clicks. A button, and, then, the android framework passes. The event, to. Our unload. More button click and. Then. We invoke this. One presenter. Got a lot more message, it, will, invoke. The use. Case inside, this. Presenter, and then. The. Use case will return, the, output to, the presenter. Fire. The. Trudy. ETS, output word there is subscriber. And then it will call, the Onyx method, so. We will have the list of messages and then. The presenter. This presenter this jet presenter will pass the output, to, the few this. One few at-at messages, and. The. Few will, show, it to the user. Ok. So we know the previous explanation, is just one. Way to interpret clean. Architecture, flow of control so, take it with a grain of salt it might, not be applicable to your use case and, the. Explanation, might be a bit confusing, so if there is anyone who wouldn't, take it offline and discuss, it with us feel. Free ok. Moving on our, next, topic is the SDK. It's. Not enough to confuse us with library. Refresh this framework now, we have, SDK. So, what do you guys think about the difference between library. Framework, and STP, well. We will not discuss, about that, in. This presentation. We. Will leave it as an exercise for, you the viewers, ok. I see, it one step further from library, Festus Rimmer previously. We have discussed, cassis chip dependency. Diagram on first and second, iteration and now, this is our third iteration, the. Background, why we design it this way squad same we, want to embed kaskus, jet in two caskets, for map now, as a crits of an engineer we have to be able to understand the obstruction, the, requirement. It's not just ambling, castro set into castle swaram it's, ambling kessaris jet into, any application.

Moreover. There, will be two. Kinds of application, one. The applications. That will use whatever UI whatever, the look and feel we have and two, application. That will use only our, business rules, because, they have their own unique, UI, the. First type the first type of application. Will use our SDK UI and the second type will use our SDK, we, decided, to separate them into SDK or an SDK, because the UI, is quite heavy, on storage, and we don't want application, that don't actually need our UI to depend, on things they. Donate. Also. We kind. Of top, foot our own SDK. And SDK UI here so, our cash, step Android, app is, actually. A, third. Party application, this. One it's. Only concern is locking. The user in just. It everything, else will, be handled, by SDK. UI and as. Su, k UI depends, on SDK it is, automatically. Top. Foot it I don't know if it's the vector Doctore, well, anyway, well. This is the third, iteration so, previously, we only have presentation. Data. And domain now, SDK. UI depends. On presentation, it, makes sense because the you I will run it presenter. SDK. Will only depend on data and, everything, else States same accepted. Me most days and, retract, man to be inside the SDK UI and. To. Simplify, the diagram. Take. A look at this two, boundaries, the, purple, and blue one, we. Have SDK. Boundary. And we have the core, boundary. Like. This and. To simplify. It even further we can. Feel. It like this so we, have SDK, and we have Korra this it, well. It looks. This, symbol, if. We look at it from this point of view but to achieve the simplicity, there are actually, a lot of complexity, that we hide under, the hood so, well. Designing, an SDK, could be another discussion by itself. Moving. On again next, topic though, shall not marry the Flagler the. Term marry here means your. Business rules depend, on the framework so, you put the framework, in the innermost layer, based. On clean up lecture concept, framework is one of many details that do not matter so. We should not marry, them right, well. Previously. We explained, about being idealistic versus. Being pragmatic and, this, is the other time for us to be pragmatic. This. Is a real case on caster, shell Android our. Domain. Layer. Depends. On our X, Java library, we. Got, married with a Rakshasa and. This. Is a conscious decision we, decided, to marry why. Because, making, abstraction. Of our rxjava, is just, not worth it our. X Java itself in our opinion, is already, abstract, enough so. This, is again, another example that. You should take everything, with a grain of salt every. System is different it's our job as a great software engineers, to decide which, thread off we have to take. Next. Topic well, we have a lot of topics. One. Interface one implementation is. It overkill. Some. Of you may have run into this kind of problem you, find yourself with a lot of bla, bla bla impl. Class it's. What what to the point you ask yourself there's. Only one concrete class for its interface, why would I need to make the interface there it's so much hassle. This is one example pay, attention that, we have locked, in presenter, interface here and. It's implemented. In login. Presenter. Impl. And if. You look closely. They. Both. In the same package the. Presenter, pivots and, so are the others, it, happened, on casters yet on the first on our first iteration. Now. It's at overkill well, the answer is no it's not overkill, to everyone interface and one implementation. However. If they, are on the same package you, might want, to revisit your dependency. Diagram but. This. Is our second and third iteration. Our. Interface. Group. Chat is only. Implemented. In one. Class, there, is my group chat, so. It's one interface one implementation, but. Now they. Are in different, package the. Interfaces, in domain layer, where. The implementation is in data, area if they. Are on different layer you have to use interface or observers. No, matter what because. That's the, one you set of interface, one usage of interface, to, achieve polymorphism. To be able to infer the dependencies, so it will be, data. Depends. On domain and not the other way around. Now. So, how do you, design an, interface, and, based. On our experience there. Are two approaches, its top-down, or bottom-up. For. Both approach we, recommend. To for. Real comment for you to read open source code you, will learn a lot there and then.

For. Top-down. Approach. First. Step is you create the, concrete, class forms and. Then. You create. And adjust the interface and then. You make the unit is for. Bottom-up, approach you. Create, the interface first, based, on your requirement. Then. You make the, uniqueness and make, it real if it's necessary, and only. Then, you implement the, concreteness and, for. Both approaches, you obviously, need to do refactoring when, it's needed, and. When. You have already, have. Your interface, you. Have to think if it could be simplified or not. This. Is the fourth prince from Soviet that we talked about before, in. The face segregation, principle. The. Espresso places, clients. Should not be forced to, depend upon interface, that they do not use and. As. Usual this is a real example from associate. Previously. We have, this one interface chat, credential, with these four, contracts. Later. When, we consume, our own SDK, we, realize that our, third-party, application, doesn't, it took care of what this two. Methods, safe, chat credential, and is locked, in. It. Just doesn't make sense to them because, stuff, party apps should only care about giving, us keeping. The SDK the. Username and password in. This case they talk, so. We, decided, to apply this interface. Segregation principle. And we split it into, two, interfaces, the. Chat, potential is defined, in SDK, and implemented. In touch party application where, the. Credential. Pref is defined. And implemented, in STD we, make, it into an interface just so we could in front the dependency. Connection. Okay. Last, topic before we conclude this presentation. Keeping. Up with things, that are, not the kardashians. It. Means keeping up with the latest technology. We. Will give you two examples first. We. Use our Xterra 1.0. On our, first and second iteration forecasted, injury and, on. October. 29th. 2016. Rxjava. 2.0, Israelis and. The. Community, decided, that they will only support 1.0. Until. March 31st. 2018. So. On December, 2017. We decided, to upgrade our rx Java library, to. 2.0. The. Second, example maybe. It is the latest one is Android. Jetpack, it's, a set, of libraries store. And architectural. Guidance to help you with. Native, Android app I, have. Not taken a detailed, look on this. Jetpack but, if you have a plan to create a native Android app you definitely. Should check it out and, the. Bottom. Line for this is you should always keep, yourself up to date with the latest technology. Okay we are at the tail end let's. Recap, what we have discussed. There. Are a lot of architectures. In this world we have hexagonal. Onion. BC BCE, and clean architecture, maybe even more we. Should not confuse, ourselves between, plot and dependency. Diagram. Software. Was the invented, to be self remember, if, you want it to be hard just make hardware, and. We. Learn about. Dependency. Infection, infection. Of control and dependency. Injection, and we. Also learn their, benefits, it's. Independent. Deploying. Therefore an easily. Swept or update, or third-party. Libraries, or frameworks. Reelin. About, flow. Of control we learn one way to implement, clean. Architectures, flow of control remember it's just one way to do it maybe. More we. Know the difference, between, library. And framework. And we. Also want to put SDK. We. Learn when. We, should, be idealistic. And, when we should be pragmatic we. Learn about one. In the face and one implementation it's not overkill. We, learn about steps, on designing, interfaces. There. Is great, open source code and then, choose between top-down, or bottom-up and. Then. Apply, the interface. Segregation principle. And. Finally. We should keep up with. The latest technologies, because as the, proverb. Says what, we learn or decide, today will be obsolete tomorrow, and. Last. But not least as always, please. Use common, sense every, system is unique every system, is different. Oof, for. Those of you who actually married. This one on behalf. Of ping, and your team I would like to say thank. You thank. You for listening to this presentation, if. You have any questions. Criticisms. Compliments. Leave, your comments below and if. You love this presentation don't, forget to hit subscribe and. If you dump some thank. You.

2018-08-18 20:46

Other news