Avoiding a Big Ball of Mud! Coupling in a Monolith

[@OllyWood688]

_"I think delegates are way underused in this context, and they're exactly that same thing; They're a contract."_ ...man. That was inspiring.

[@CodeOpinion]

Not sure if you're serious or being sarcastic? I know sometimes I can get a bit monotone.

[@OllyWood688]

That was genuine admiration :) ^and this is not sarcastic either, please believe me aaaaah Sometimes I catch myself looking for elegant solutions in the most complex of approaches, but overlook that many things already are functional in a simple, elegant, and obvious way. That's what I meant with inspiring. No need to piggyback a huge ass nuget if what you want to accomplish can be done with just some minding the tools you HAVE. Thanks for the reminder to stop and breathe a little :)

[@CodeOpinion]

Thanks 👍. I really do appreciate the comment.

[@AntonioCastroJunior]

Hi Derek, How would you organize the solution to have separated modules but just one database with schemas for each module? Is it ok to have a separated project in the solution with, for instante, an EF context referencing the entities directly like: public Dbset Orders{get;set;}

[@CodeOpinion]

Each module/project having it's own DbContext. They shouldn't share or have any of the same DbSet however.

[@AntonioCastroJunior]

@@CodeOpinion Is it possible to have multiple DbContexts pointig to the same database with different schemas? How migrations would work?

[@CodeOpinion]

@@AntonioCastroJunior Yup. Each dbContext will have it's own connection, just pointing to the same DB instance.

[@adamali89]

I really appreciate your efforts!. I wish if you would create series on identity server with monolith and boundaries that how one should implement authentication and authorization with all these concepts.

[@CodeOpinion]

I'll add it to the list of topics. Thanks 👍

[@yevheniikurtov5990]

Derek, there is a very dangerous slip of the tongue at 1:29 - boundaries are defined in collaboration with domain experts. This problem can't be solved exclusively within the engineering room.

[@CodeOpinion]

Of course.

[@argentum_serebro]

Hi Derek! Thanks for the inspiring ideas you're presenting in your videos! If you would get a tasks to decouple a so cold "ball of mud" monolith how would you approach the analysis for future refactoring ?

[@CodeOpinion]

Find the boundaries. Leverage events to start decoupling. I should create a video on this topic!

[@argentum_serebro]

@@CodeOpinion that would be awesome! Looking forward to it!

[@romanlunin386]

Hi Derek, according to the Clean Architecture you could create an even looser coupling by defining contracts inside the same boundary, e.g. define IWarehouseInventory under Sales boundary, this way Sales has no foreing dependencies at all, do you think it worth it?

[@CodeOpinion]

Yup, you could if you would get benefit from having that interface. By all means, if not, don't bother creating an abstraction with a single implementation.

[@thilehoffer]

How do you inject an implementation without a project reference to the implementation project?

[@CodeOpinion]

Ultimately the executing project (aspnetcore) is doing the injection and has all the references. So you only need a reference to the interface/delegate.

[@thilehoffer]

@@CodeOpinion Thanks for the response. So the asp.net core project can reference all the implementations but the other project only reference the contracts. Also, I love the idea of using delegates instead of always using interfaces. Good stuff.

[@antoniocastrojunior684]

Hi Derek, in my experience, systems always start small like a baby, but babies grow. Implementations calling contracts outside their own boundaries seems like syncronous api calls. What do you think of using messages just from the beggining in order to minimize the impact of changes when you need to separate a module (boundary) as a microservice? Thanks for the great series.

[@CodeOpinion]

Ya I've been advocating messaging within a monolith. However I wanted to create a video that if you're not going to go the messaging route, or already have a large project that makes synchronous API calls between boundaries, to do so via interfaces and delegates(functions) that are defined in a separate contracts project.

[@janhendrikschreier]

I am just reading Enrico Buonanno's book Functional Programming in C# where he also suggests more delegate-usage. Thus your video on using delegates arrived just in time for me:) I liked the demo-part with the registration of the delegate and and how you make it part of the contract with an extension method. thanks for the video!

[@CodeOpinion]

Shhhh... don't tell anyone I'm trying to slip in some functional ideas into these videos!

[@janhendrikschreier]

@@CodeOpinion I continued reading the book and now I know where this will all end: "In the last chapter, you saw that in FP we avoid mutating state, especially global state. Did I mention that the database is also state, so it too should be immutable? What? Yes, didn’t you see this one coming? A database is, conceptually, just a data structure." aaaaaahhh! If someone had told me before! This whole FP stuff is like watching a KZbin video on how to boil an egg and five hours later you're convinced that Lizard's rule the world ;)

[@andrewthompson9714]

@@janhendrikschreier this book changed my career. I recommend it to every c# developer and it's required reading on my team

[@janhendrikschreier]

@@andrewthompson9714 If you liked that book, Grokking Simplicity is even better. It uses Javascript in its exampled but as a c# dev it is easy to read

[@stuartbradley5761]

Hey great video and great series. I've been spending some time looking at modular monoliths and loosely coupled monoliths as I've had bad experiences with big balls of mud. However I'm stuck on one area which is querying. I follow CQRS and use entity for my commands and dapper for my reads. Should I query across boundaries? The UI might require information from two different schemas. Any advice?

[@CodeOpinion]

You will need to do composition somewhere. That can be in the UI by making multiple queries. If that's not ideal in your situation, you can have the server do the composition so you only have one call to the server from the client. You can also develop UI components that are owned by a specific context and use those to build a composite UI. Is a big topic :)

[@richardbrown1300]

@@CodeOpinion I'd love to see you do a video on implementing UI in a loosely coupled monolith. This is a great series

[@Cypressious]

In response to delegates, couldn't you just split the interface into multiple interfaces and let the class implement all of them?

[@CodeOpinion]

Yup. However, if you have an interface with one method... you just want a function. But yes, maybe split them into more specific interfaces.

[@Cypressious]

@@CodeOpinion you're right, but interfaces need a LOC less to register with the DI 😃

[@matthewbrookson]

Libraries like Moq also solve this testing problem that was mentioned by only requiring you to implement the "fake" or mock methods on the interface that are actually required for a given test. I like the delegate idea but can see class constructors becoming very bloated as you require more delegates to be injected.