Highly COHESIVE Software Design to tame Complexity 

Do you primarily think about cohesion in the sense of informational cohesion or functional cohesion?

Every time you remove mocking code from a test, it’s likely you’ve improved your architecture. Very nice as usual!

I have the impression that the problem you solved was just migrated to higher level. I believe there is still a need for this mock test but on the function that calls the handler since the implemenation of this delegate is still required

"When I'm thinking about cohesion, I'm thinking about functional cohesion. Not informational cohesion." -- precisely clear!

Great content! I always thought this idea of having a service per entity that does a lot of things was a bad idea. In your example, you have only a few methods, but I have seen "entity services" with a lot of methods and large methods. One thing I love in CQRS is that if I have a "Create Product Command" it only needs to change if the business rules for creating a new product change. But if I had a ProductService with lots of methods, this class/interface could have many reasons to change(for example if I change the rules for another method but the CreareProduct). The delegate approach you show in this video is very interesting, I'm gonna try to add it to my projects when I have the opportunity.

Thanks a lot for sharing knowledge!

You have done such a great job at explaining things. Really good job dude! Keep it up and greetings from Poland!

The problem with uncle Bob's definition is that it doesn't describe the cohesion boundary. Cohesion is about what is controlled from within the boundary. If you make the boundary too small, control is outside that boundary, if you make the boundary too large everything fits inside, but it's now the whole system. Discussion about the boundary line is what uncle Bob and many others talk about, that's the process of sizing a module, but that isn't the definition of cohesion. You need to iterate through different boundary options where cohesion is optimised and module size is minimised. So cohesion itself is not the size, it's the criteria for internal control of resources (and dependencies). I will be writing some much clearer articles about this, this year.

Amazing and easy explanation

I used to go on a lot about cohesion and coupling, and while they influence my thinking, I feel like they are derivative of things that compose well. Making things that compose well is much more interesting and drives cohesion and (de)coupling. It also influences knowing when cohesion and coupling don't really matter (ie, things that don't have to compose well with other things)

Nice

What was the difference between the two implementations showed in this video? Why the last test should've passed?

I do agree with all you say in the video, but sometimes I tend to group behaviors based on the likelihood of them having to change together, even though they end up not being used together

Hi Derek! Again another eye opener video. I like the idea of functional cohesion. It fits and reinforces the idea of the vertical slice architecture where every slice is a high cohesive unit that goes hand to hand with the bounding context concept. But I have a question, the way you split entities by "function" can't lead to duplicate fields in different bounding contexts that will have to be kept in sync? Isn't this something hard to do? I mean if you have the warehouse bounding context and the sales bounding context that both have their vision of the product entity and now someone notice that the sku is wrong and needs to be changed (I just picked the field common in your example, can be any other that is shared) how would you go to solve this issue? It can't be changed in one place, it needs to be changed in every different "Product entity" owned by every bounding context. Please could you comment a bit about it? Thanks!

How does DI work for the delegate and the method implementation?

Haven't really heard much about delegates in .net core c#. Do you have a video on this?

Thanks for making great videos. I agree with what you're saying about cohesion. However, I don't agree with the delegate solution you proposed in this video. Generally, there's nothing wrong with delegates, they're very useful! By your own definition, in the video, a class should only do one thing. The product service does 4 things. Updates product info, gets by SKU, gets for sale by SKU, and gets all. I don't think that's a bad product service, I think it's fine. BUT, if you wanted to hide the implementation details you would inject an interface for EACH of those functions. IProductInfoUpdater, IProductSkuGetter, etc. (Forgive the shitty names, sorry.) Maybe CQRS? Basically, I don't think you should use delegates for this particular example, in fact I'd say it's a bad idea, but I agree with the principal conclusions and I enjoy your videos. Thanks.

how do you maintain correct sync between systems in a microservices environment? especially if data is common data is shared between them?

Should all the products under sales, warehouse and purchasing needs product name as well?

I maybe missing the point, but I'm not really sure what the gain is here. You are substituting an interface dependency (IProductService) for a static class dependency (ProductDelegates). I don't see how that changes cohesion. I prefer the inline mocking code in your case, but you lose the ability to use things like .Verify(..., Times.Once) from Moq.

Wait I don't understand, why is the test passing at the end a good thing?

I lol'ed because in your de-coupled products you can only ever *increase* price and cost. You can't decrease it. Commentary about our economic system hidden here ;)

Never depend on things you don't need. It sends coupling through the roof and confuses the domain responsibilities

I think you have jumbled together the concept of views with entities and database (de)normalization. None the less, it's a good point that software needs to consider functional and domain aspects.

Well, that code example part seems strange to me. First of all, you have 3 get* methods, but only one is actually used. I'd say, you either don't need that methods in the first place, or you will need them in your handler eventually. Keeping in mind this is made up expample, in real life that handler will (!) need more methods from service after some time. My second thought is that you still need a real implementation for the delegates, which has to be placed somewhere - you've said it in the video, but did not showed it. So the service stays the same, but now we should be searching for the implementation in our project, which slows debugging. Third thought, testing should not affect developing. Those two methods happened to have the same input and output, but in real life you'd need to change that test. After all, changing tests when we change logic is ok, so this approach have no benefits compared to mocking (where we'd need to change mocked method). But mocking have benefits in terms of clarity. With mocking, when I read a test, I can easily see what's happening. I can see, that, if service returned that object, result of this hadler should be that. And I can easily find tests in project for that method. "Delegate version" of this test tells me much less information. If some random method returns some product, it's somehow will be returned from Handle method. What this test actually testing? Delegate invoking? I hope Microsoft done it for me. And your example shows exactly that. Test did not reflect changes in code, so you're testing only a fact that injected delegate got invoked, whatever delegate it may be. I'm not sure that is something I want to test. After all, now the same problem could appear instead in injection logic - we set up a wrong service's method for this delegate and now our tests did not told us about it which defeats whole it's purpose.

Thanks for this video! I like the idea of taking the dependency on the delegate, however, it's not very clear to me how to test the delegate's implementation. Say, I have something like services.AddScoped(x => { ... }); How do I test this? Thanks.