The 6 Figure Developer Podcast

Episode 074 – Libraries vs Frameworks w/ Dennis Doomen

Jan 14 '19

Dennis Doomen is on an everlasting quest for better solutions that will significantly improve the efficiency, the quality and the productivity of your software development teams.

And among other things he is the author of Fluent Assertions, an API for asserting the results of unit tests in .NET.

Transcript

Clayton Hunt: With us today is Dennis Doomen. Dennis is on an everlasting quest for better solutions that will significantly improve the efficiency, the quality and the productivity of your software development teams. Welcome Dennis.

Dennis Doomen: Thank you, thank you for having me.

Clayton Hunt: So before we get started, would you give us a little bit of introduction about yourself, maybe how you got started in the industry?

Dennis Doomen: Ah, wow. 21 years and counting, absolutely. I actually don’t know how I end up in this business. I mean, I just liked software development since I was young, I had a [inaudible 00:01:10], maybe you remember that. I had a [inaudible 00:01:14] as well, and started programming a C and C++ at the time. Somehow, I ended up in the non-IT business, but I did a little programming outside my job and then I decided to make it my profession. I’ve been doing this, for yeah, basically as I said, for the last 21 years as a professional software developer consultant.

Dennis Doomen: Last 10 years I’ve been speaking a bit, doing some open source development as you may have heard. I enjoy my work; I am passionate. Love to talk about it.

Clayton Hunt: Very cool. I was able to catch one of your presentations in Orlando a month or two ago on dependency injection and inversion of control. You want to maybe give us a high level overview of what that talk was all about?

Dennis Doomen: Yeah. It was mostly driven by the fact that I ran into a couple of architects, experienced ones, that were telling the teams like, “You should not use dependency injection. It’s evil. It’s going to hurt you. It’s going to … I don’t know, bring your code base down.” And then I started to think about, why is that? Why are people somehow rejecting something? And the same happens with [inaudible 00:02:28] relational mappers, for instance. And I started to think about that, and I realized that probably everything is … All of this whole attitude or mentality is caused by the fact that we misuse something.

Dennis Doomen: Every tool has its advantages and disadvantages. If you understand that, you also learn when something makes sense or not. Dependency injection is one of the examples that you can easily take the wrong path. If you take the wrong path, it’s going to hurt you. TDD is test-driven development; it’s another example like that.

Dennis Doomen: I started to think about, okay, what is it? What people … what frustrates them or what are the pains of dependency injection? And tried to come up with some examples that tried to keep you away from that and make you successful Or at least I would say successful but at least allows you to solve the problem in the way it was supposed to be solved.

Clayton Hunt: So what were some of the kind of misdirections that people were using? Sort of, dependency injec- yeah, dependency injection [inaudible 00:03:28].

Dennis Doomen: Yeah, that’s a good question. The people say stuff like, they hide the magic. You don’t actually understand or it’s really difficult to reason like how does an object get resolved and how did the dependencies get in? Where are they registered? They say that it is force it’s kind of … and other situations where all unit tests successfully complete and then when you run the application stuff starts to fall apart because you’ve never actually verified that your registration code is doing what it’s supposed to do. They also say it’s not always clear when your dependencies are created, when they are disposed for instance? And stuff like that or because diamond dependencies or unreadable bootstrapping codes, you may have seen those pages and pages of registration codes. That’s kind of the thing. And there’s one of course, the overzealous faking and I don’t do a lot of fakes anymore because I’ve changed the way I work these days, but you also see that quite often that people create a class and then they create the “I whatever” class interface next to it. People blame this all on dependency injection, which I think is not fair.

Clayton Hunt: Hmm.

Jon Ash: Yeah, and you had some interesting ways around that so that you don’t necessarily just automatically create … get an interface for the implementation class that you’ve already written. You were using delegates and some other language features. Is there a way to discuss that without using visual aids?

Dennis Doomen: Well, I would say it’s not necessarily about delegates, although delegate. Well yeah, there’s one of the examples that we discussed I think is that somebody takes a dependency on the funk of something, you know, and typically that happens because it class wants to be able to decide when it creates an instance of that dependency. It’s kind of a factory implementation if you’re trying to include the design patterns. I’m trying to figure out how that’s funk gets resolved or how does things gets registered in a container can be pretty complicated. And one of the examples I think I gave was to define the delegates a names delegates. Now one of those C-sharp features, that’s and I see everybody’s shaking their hat now in the video, it’s the listeners can see is a C-sharp, one point or feature where you basically define a second job.

Dennis Doomen: Maybe you want to be able to resolve, let’s say in an order repository, something you just defined a delegates with the name gets order repository, which gives you that I own a repository and you can actually register that somewhere. The cool thing about delegate it’s named, it’s a type in.net, so you can use your whatever tool, a visual studio or ride or whatever tool you use to figure out where it’s actually registered, which is much more difficult with functions, actions and stuff like that.

Jon Ash: I don’t think a lot of people know this because they’re not too familiar with delegates, but I mean really funky inaction or just Microsoft provided generic delegates.

Dennis Doomen: True.

Jon Ash: I mean they’re just … here’s the delegate that we’ve made because we know it’s common and it has 16 different parameter placeholders that you can use. If you look at the decoupled sources since the credit law, even if you tried to look over the overloads, it’s truly yeah.

Dennis Doomen: Yeah.

Jon Ash: Yeah, in a way you named delegate. This is exactly what it, what it, what it says it is. It’s a named delegate. Something that captures the intent of that thing and it’s very discoverable as one of the little tricks I use a lot.

Clayton Hunt: Yeah, and in one other talker or presentation that I saw in your library of talks that you do in and around the community was something around building libraries and frameworks. Do you want to kind of give us the high level overview of that one because just the title alone really resonated with me.

Dennis Doomen: It’s true. It’s again, trying to solve a problem that I’ve been trying to solve for years and the thing is that when you, when you started developing, you become fluent in your language and at some point you reach a point in your career where you have to work with people that you could say less or goals or lesser experienced people and what you’re trying to do is reduce complexity.

Dennis Doomen: And one of the things a lot of people do to reduce complexities, to create abstractions because yeah, working with instructions generally means that you don’t need to understand the details. So what happens is the restriction abstraction is changed into a framework. There’s the framework are supposed to solve a common problem. This seems like it works and usually it works for a while until you run into a situation that you need to support something that the framework doesn’t support out of the box.

Dennis Doomen: And then you started to figure out, okay, how do I actually make this framework, do whatever what I want to do, and you’re starting to go into the details and then it becomes ugly. Some things are too complicated and you should never be able to, should never want to be able to go into the details, but generally frameworks try to abstract a pattern and if decode, if the problem that you have does not meet the pat on, yeah, you’re kind of stuck and I’ve learned that over the years and again, the 20 plus years, that framework is probably not always the best solution.

Dennis Doomen: Maybe it’s actually better to build a library that doesn’t hide, that doesn’t have the magic. I kind of forces you to understand what you’re building because in the end of the day the framework will enable something. But I mean requirements changed, at least in my world, the requirements all the time and my product owner changed his mind. At some point you need to understand the details. So I’ve started to organize my systems and whatever I build library, systems around, building blocks that solve small problems and eventually if you combine them, they solve the bigger problems instead of trying to come with this super component that tries to solve all your problems until they don’t.

Jon Ash: My favorite is the companies that are going or attempting to go to microservices and they have a monolithic framework that they built and say, Oh yeah, just, you know, use this framework for this new microservices we need, but the Microsoft, this is literally one method and you’re asking me to do downloads, gig framework for this. That just doesn’t make any sense.

Dennis Doomen: Yeah, that’s one of the … Yeah, that’s true. It is one of the side effects or advantages of a library instead of a framework. But of course a library if you build it, like that also means you need to really understand all the details. You need to understand the nitty gritty of how to think is supposed to work. So the learning curve is, I never know what it is. Is it more steep or is it more … It takes more time to become productive with it. As soon as you are productive, you may be able to solve different problems that you didn’t expect that that library can solve for you.

Clayton Hunt: Do you have any thoughts or opinions or just tips and tricks to developing a library and like how do you find that sweet part in delivering just enough but not too much and maybe not breaking it up into thousands of microscopic libraries into, you know, this is just enough for logging or something like that.

Dennis Doomen: Well, It’s interesting you say that because I do have some principles that I follow and for the record I did an event on myself. Robinson Martin talked about that for the last 20 years and it’s realist of all the principles that I follow actually of course you have to end up with more packages, with the idea is that you have sort like a main package. You could say the main package contains, you could say a bunch of classes. Each of those classes can be used directly, each solve a specific problem, and then usually you have some convenience clause on top of that that combined those building blocks in a way that solve common problems. But the point is they should not use inheritance, which could be difficult to do, but I actually failed for composition of inheritance. There’s a bit of a dogmatic thing I would say.

Dennis Doomen: But by defining your package of small components, there’s a bigger chance you can reuse them. So the main package contains building blocks that are usually used together. Anything that’s in that package that is not always used with that main package should be moved into separate package. I called an accelerator package. This also prevents or avoid situation that you’re going to change one class of that package resulting in the new version even though like 90 percent of the package hasn’t changed. So you’re trying to avoid interrelated changes leaking through to your main package. It’s kind of the single responsibility principle, but then on the package level.

Dennis Doomen: The same as like your package should not depend on anything that’s less stable than you. You should only depend on staff that’s more stable than you because if you depend on something that’s more stable on you and there’s less a chance that you have the ripple effect that we all know the DLL how so depending on, for instance, in adult [inaudible 00:12:36] world, we all know maybe the Owen Library which has had one version and I don’t know, earning the 40 million downloads, that’s fine.

Dennis Doomen: Depending on maybe something like new too soft you know Jason, which seems to have like a three for breaking releases per year. It’s not a smart choice here. It’s a bit difficult, you really need to see the picture of course. But, I want extra if you depend on something like … If you’re a package can work with, I don’t know, external things like let’s say you have an arm that supports an [Iben 00:13:08] aids or entity framework. You should actually not at a dependency to an [Iben 00:13:13] aids on your main package, which should have an extra package. It tries to connect the two. Does that make sense?

Clayton Hunt: Well, those are all. Those are all the extended versions of the solid principles, that uncle Bob has defined I can’t remember the names of all of them, but it’s a … can reuse equivalency a principal stable abstraction principle, a few others, I feel like there they’re the solid principles, but on a much larger scale and-

Dennis Doomen: And backend [schlafly 00:13:44] you could say, or component level maybe even.

Clayton Hunt: Yeah. And it’s difficult for people to grasp the solid principles at the level of they’re intended to be applied. And so it’s even more difficult sometimes for them to grasp the package principles or the module principles.

Dennis Doomen: Yeah, that’s true. And one of my slides, I have a slide decks. I have a slide that tries to capture it. I always used that as an example because it helps create this mental picture.

John Callaway: You’re right.

Jon Ash: Oh, you keep saying a package which is relatively new term for.net engineers. Normally we think libraries or projects. When you say package, does that mean that you are separating things out into separate nougat packages or just other projects or even other folders within the same project?

Dennis Doomen: That’s really good question actually because it’s all of the above. So initially the presentation that we had just discussed was about separating your code into individual new get packages which maintain dependencies are controlled dependencies. But I’ve also seen that the same principle can also be applied to a single solution. Let’s say you’re building a big system, you can define projects and really think about what should be in the product, what should be a separate project and whatnot. How do you combine everything? But I personally believe that and I think Jeremy Miller once mentioned this in a blog post like eight years ago.

Dennis Doomen: I don’t create projects to control dependencies. I only create separate projects because there’s a deployment concern. So what happens is that the same principles are now applied within the projects within follows, within the projects. So what I want I tried to do is kind of feature full lists.

Dennis Doomen: I break down my code into folders that represent functional or technical features and then I really try to prevent creating connections between those [inaudible 00:15:40]unless it was designed for that, requires a lot of discipline to be honest, but the same principle applied as well.

Jon Ash: Awesome. There’s been some discussion recently on a number of projects that I’m involved in about combining a lot of repositories into like a large monolithic repository and also read about the same in the devops handbook, but like you said, it does require a lot of discipline because there’s nothing preventing an engineer do reference something in a folder that you didn’t necessarily intend for them to have access to you?

Clayton Hunt: Yeah, and that’s really easy with tools like [reshuffle 00:16:17] it’s a simple [halt 00:16:17] and to have the connection. Yes.

Dennis Doomen: Well that’s where we have pulled across reviews, but obviously it doesn’t help that much. You can see it from the namespaces but merging different projects into the same rapport would also mean for me that have the same release life cycle. That’s also important because I also mentioned in my presentation that’s great libraries have a clear re-strategy, a semantically merged version, you know, stuff like that is also part of that. If you merge that and then they must have the same release cycle, it usually if you break down something into small[inaudible 00:16:49] packages, they probably have differently really cycle. That’s why you want to separate them.

Jon Ash: Do you, when you’re working with your teams, do you have issues or have you worked through sort of getting everyone to follow those disciplines and getting people on board? Has that been an issue?

Dennis Doomen: It’s really easy. They just do exactly what I want to fully understand my mental model all the time.

John Callaway: Spend the next hour talking about how you get that.

Dennis Doomen: It’s really hard because I look at … The thing is a lot of developers have to tendency to dive into the details and gets, I don’t know they get swallowed in the details. They can swamp. I think that’s the word for that, and they are trying to make something to get something to work and then they forget like the big picture. Like where is this little thing supposed to play a role? What is the boundary? This is the most difficult thing. I think I used the word boundary a lot these days, with my teams because it’s really difficult to figure out or create a clear picture of what are the boundaries within your system and a boundary is also the boundary defining the boundaries of your package, but it also the boundary of a feature. And if you include TDD for example, the boundary also defines the scope of your tests that you’re writing.

Dennis Doomen: And that’s really difficult and it’s not always, it’s not just difficult. There’s also open for debate quite often.

Clayton Hunt: I often get caught, I guess because the rules from the business are not always clear as to how the application should be broken down. So I try to start with a minimalistic solution in an attempt to understand the flow of the application before I break it up into its individual pieces and, and figure out what pattern is going to be best for this application. But then all the other devs that aren’t also thinking that same thing jump in and they go, oh, look, a pattern, they just replicate whatever terrible thing I have done throughout the entire system before I have a chance to stop the spread. And then it just issues chaos for quite a while.

John Callaway: It is. And I see that quite often. Like I’m looking at somebody else’s code base. I’m looking at a solution on one that like, why are we doing these thing this way? Why are we not actually looking or reconsidering the scope lifted test or something like that. And then the answer is, yeah we always do that. Why?

Jon Ash: Because that one person did that one time.

Dennis Doomen: Yes, somebody actually thought about it and he probably had a really good reason for doing that. But yet then inflammation gets somehow lost in translation or I would say most indeed noise commits and you’ll get a proposed story. I tend to do that quite a lot. I tend to sometimes take some time, look at the solution. It makes me a bit slow in product from a productive side, but I reserve time to reconsider a really look at it. Look again at the big picture.

Jon Ash: I think it’s really important. That’s what ends up happening is I’m forced to spend three weeks doing something that another developer would spend a day doing.

Dennis Doomen: Yeah, and then the next time somebody says, oh, don’t let the trades and just because it’ll take you more time.

John Callaway: Then I recognize that. Right. Let’s switch gears just a little bit since we’ve mentioned TDD and testing a number of different times and one or two touch base on your. You’re the author of the originator of the [flu 00:20:06] and assertions library. You want to tell us a little bit about that?

Dennis Doomen: [Flu 00:20:02] into assertions? Yeah. It’s a little project of mine. I’m moderately successful, I would say, I don’t know. I like fluent KPIS. For some reason it was started at the time that we just had MSS nothing as popular yet. And it’s essentially an API to make your test a bit more readable, especially the assertion parts because that’s the only thing It can, it depends on the boundary, but I strongly believe and automated tasks that have a clear cause and effect. If I look at the unit test, I should be able to figure out first from the name, what is this thing supposed to do, what’s the functional scenario? And then I look in the implementation and that should also be really clear. What’s the entry? What’s the starting situation? What is the action that’s being executed?

Dennis Doomen: And then what’s the error that happens. And again, I can quote Jeremy Miller he once set like, “You should be able to keep out of the debug hell.” So I kind of started throwing insertions so that if a unit that fails, it gives me really clear message like what’s going on there. And I also don’t love reading myself. So over the years some API have evolved, well emerged that allow you to bear entire object graph, emphasize the parts of the EAPI that’s really relevant. It’s really difficult to explain that by the way, over audio, you have to. You have to actually see the EAPI and the syntax for especially the failure message if something fails. Yeah.

Jon Ash: Yeah. I find the method that I use the most should be equivalent to.

Dennis Doomen: It is one of those three powerful. It’s almost like a freight broker. Sometimes you need to understand the magic to see what’s happening. I haven’t fully realized that. Yeah, It allows you to compare the object graph even though they are not the same type. It’s really beautiful to compare against anonymous type because then you can actually say this object shoots match this anonymous type but only include the properties that you here about. And is really smart about how to deal with collections by default. It resumes collections are in order. I will also try to give you a really clear details like when two collections are mismatching. That’s pretty powerful thing.

John Callaway: I mentioned that it started primarily with [inaudible 00:22:19] framework. You said with Ms Test, I’ve been using it in.net core with axion and so how has that evolved over the years and do you have a lot of contributors or how do you manage that?

Dennis Doomen: It kind of started the project started to, I don’t even remember when probably in 2008 or something together with a colleague of mine, Martin Olddumb, and as every open source project starts, that’s usually something you tried to fix for yourself and then you extract it. We had quite some breaking changes over the years. We’re now at version five, but it wasn’t a nice learning school to understand how to deal with the diversion ability of EPIS and how to dealing with that contribution wise, I don’t know exactly when it’s hard to really kickoff because these days it’s like a million downloads a month or something, but in the beginning of it was mostly me and Martin and then he had asked people started to join. Especially when I moved from complex to get up. Things really became to change because yeah, cold black, she had to deliver patch that they’ve never really worked.

Dennis Doomen: I also never had to support multiple [inaudible 00:23:18] at the same time, people are generally willing to upgrades and I also consciously tried to postpone all my breaking change into the next major version. There’s a couple of people or a novelty maybe you know, him. Is the react guy. He held lots of supporting PCLs a portable class libraries, I think no, no, we actually started with copying files using linked files, you know, because we have to support different document frameworks and then we had to support MB unit and actually needs an AU unit and I don’t know how many other units we have. That we move to PCLs and then I think later we moved to share projects. You can also see that the project actually evolved with all the visual studio versions and all the platform around it especially Owen helped me a lot with the PCL part because he knew all the PCL numbers by arts and he said, “Ah, you have to do a PCL four, five, seven.”

Dennis Doomen: They’re like, “wait what is that”? Yeah. And then the shared projects came, was still bit of I would say paint to sport, all the frameworks. But everything became much nice and when we have these new cross compilation things in the latest[inaudible 00:24:15] versions makes it a lot easier for people to contribute and can see that. There’s always a couple of poll requests available. But it comes with a cost. I mean you also have to sometimes say no, cause people want to add extensions and you don’t want to support that or make it really difficult to extend that to keep the system. What EAPI consistent.

John Callaway: Is a community understanding when you have to have those conversations or when you have to decline or saying no to those types of things. How supportive is the community around this project?

Dennis Doomen: It’s a good question. I would say generally yeah, people are pretty supportive because I also sometimes get like a public class that somebody is already like[crosstalk 00:24:55] I realize it doesn’t really fit into the existing API really well, but maybe we can have a discussion about that. Slack also helps because sometimes the discussion starts in Slack like, “Hey, you know what? I want to. I want to support something like that. Would it be possible?” Yeah, I would say yes. I didn’t have any fights. Maybe people don’t want anymore today, but generally it’s under which stays behind it. Absolutely.

Jon Ash: Yeah. I’m here to check it out. I have, I’m new to me. So I enjoyed hearing the testing and we do it pretty, pretty heartily and sounds like it could really help us. Yeah, I think I’d try tried out fluid assertions 2010 to 2012, somewhere around there. At the time I was going, I was experimenting with different, uh, different libraries and stuff that could help me with testing and I actually didn’t stop using it for any, like, real good reason. I stopped using it because of the word should a little bit of a wiggle word and there was quite a bit of talk going on at the time about how don’t you should, don’t us, should or don’t. You should just say the thing it does this and then if the test fails it’s because it didn’t do that.

Dennis Doomen: At some point I even considered and we discussed and see which checking over that would be possible to use the word lost instead.

John Callaway: Yeah I think, it may not be a C-sharp flavor, but I think something does use must done.

Dennis Doomen: It could be.

John Callaway: Maybe it’s a Javascript thing.

Dennis Doomen: So, these days it’s mostly me and Yonas Nirup which gives [inaudible 00:26:35]I never met. He’s doing a little work. He’s pretty critical in the code reviews. That’s a pretty standard thing is kind of feature complete. The people always come up with new ideas of how to make it nicer and it’s also more difficult because you really have to think about backwards compatibility and especially all the overloads and stuff like that. That really has caused us some issues like recently we released a version and we did some internal refactoring and we never anticipated somebody to use your library in a way that they were using it costing like binary compatibility issues. It’s also because there’s quite a lot of extension or libraries that did extend fluent assertions and provide … this is something I never realized.

Jon Ash: It sounds like a really good experience in designing systems of that scale.

Dennis Doomen: Absolutely. I mean, I learned about polar quest. I learned about designing systems and APIs. I learned about quality guidelines also because I’m a pretty … I’m a kind of a C-sharp coding guidelines guy. I have guidelines for the last, I don’t know, since 2001 as also you need to find the you know, kind of middle ground between what do you expect from contributors in terms of quality level. Are you willing to do some cleaning up afterwards just to, you know, make it easy. It’s something I’ve experimented bits. There’s quite a lot of literature on this as well of course. But yeah, I try to be accommodating as well. Yeah. Yeah. I was just checking while we talked about this project was looking at the get up statistics. I didn’t realize there’s apparently 281 forks and I had 104 contributors. So yeah, that’s pretty happy with that.

Jon Ash: So a significant portion of our listeners are more junior, or they’re looking to sort of either get into the industry or kind of really grow themselves, step into kind of bigger roles and grow in their responsibility and in you know, approach, approach of things. So, do you have any advice or words of wisdom that you might be able to sort of target them specifically on how, you know they’re just getting started and, or how to kind of, you know what should they focus on to really advance themselves?

Dennis Doomen: That’s a really good question. I wish I had some time to think about that, I would say the thing is our profession is too broad these days. There’s too much stuff to learn. I would definitely avoid trying to say I want to become an architect because that’s where the money come from. Well I wanted to become a manager. I just happens magically I would say participate in open source projects because there are kind of … And I don’t think it applies to all projects, but I would say an opensource project could be a nice environment where you can learn from others.

Dennis Doomen: I mean especially if you’re in a place where you don’t have any senior people you know, to learn from an apostolate people, an opensource project, he can’t give you a different perspective on it. I also think going to like meet ups, like a user group stuff is a really nice place to share experiences. Even if you’re a junior or something, at least you can hear other people talk about what they think or ways of solving problems and don’t take it for granted. Don’t take it as the absolute truth.

Dennis Doomen: Don’t take anything I tell you in this podcast as the absolute truth because something that doesn’t exist but in this fence, different ideas and opinions and put that in your I own a mental backpack or something. So by the time you need to solve a problem, you may remember like, “Hey, I’ve heard this guy talk about that. What is goal or whatever.” And maybe this could be a solution for my particular problem, but don’t focus too much on trying to keep up with everything. Just listen and observe and try to spar without a people again. Yeah, it’s really difficult to give generic advice of course. But yeah.

Jon Ash: That sounds excellent. I think that’s really, really good advice. Do you have any resources that you might point people towards for like either whether getting into dependency injection or try to figure out how do we build better solutions, that sort of thing?

Dennis Doomen: Yeah. Obviously Roberson Martin has been an important source. The guy has been around for years and it gets a lot of criticism these days. This is the stuff that he wrote still so [fallot 00:30:45], to Robert’s Martins book in general,[inaudible 00:30:49]to follow. Also wrote a couple of books which really, really are still completely accurate. Everything they say still applies to our job.

Dennis Doomen: I would also say Michael Farris, he wrote the book about dealing with legacy code, especially his characteristics test is something that everybody forgets about it, but I still find is really useful to you know start with unit testing on existing code base, my own blog, obviously I tried to capture my own experiences cause I use my blog kind of a way to essentially compile things I ran into and something that I can remember for the past. Well, I don’t know, I don’t have that many different options specific people that I really follow. Jeremy Miller, I would say definitely Jeremy E Miller, the author, a structure map and a couple of local libraries as written it, a couple of really good articles. I think they were called like Jeremy’s first law, TDD second law that really kicked off my interest in TDD and all of them are still completely applicable in the current state that we are.

John Callaway: Excellent. if people wanted to follow you other than obviously your blog, is there any other places or ways they would be able to do that?

Dennis Doomen: Twitter, of course, much were a ID. I’ll shout out it’s deed human, which is difficult to say. People probably don’t know how to spell it. If you want to improve the level of your coding guidelines or a C-sharp language, you can check, www.csharpcodinguidelines.net, I think there’re shared links as well. It’s a ripple store Integrate Joan coding guidelines, but generally, I mean, liquid projections is one of my recent projects which is for event sourcing business systems is a library that I really tried to build with this whole you know dependency management principle minds. I started with that before I started to think about that, but it really redesigned and extracted everything as you kind of an example for that.

John Callaway: Awesome.

Dennis Doomen: There’s quite a lot of resource.

John Callaway: I guess lastly, do you have any upcoming speaking engagements that you might be able to plug?

Dennis Doomen: I had a bit too many speaking engagements this year, so it’s a bit more quiet till next year. I do a talk on the DDD exchange in London in June and a couple of local things in Netherlands, but no big things planned anymore. Not yet. I might change my mind.

John Callaway: All right, thanks Dennis. This was a lot of fun.

Dennis Doomen: Thank you. Thank you for having me. It was an awesome experience.

Links

The 6 Figure Developer Podcast Follow

Episode 074 – Libraries vs Frameworks w/ Dennis Doomen

Transcript

Links

About package design

About Dependency Injection

About Dennis

Other resources

The 6 Figure Developer Podcast