SOLID Principles? Nope, just Coupling and Cohesion 

You just described why I created this channel and what I try to post videos about!

Yup. There's many different approaches you can take if you narrow it down to coupling and cohesion

Thanks, appreciate the comment. I don't think of them as bold or have any intent of being against the grain for views or whatever. Just speaking what I think.

Glad it helped.

Good suggestion for a video!

I do and don't. The blue DDD book is one but hard to digest. I've been more into certain individuals perspectives and conference talks.

@@CodeOpinion that would be interesting to hear!

@@CodeOpinion It would be pretty interesting to see a video from you about talks, books, blogs, etc. that you have found useful and learn form.

I like clean code. It really instilled in me the importance of sticking to my guns and taking some extra time to making things better than when I found them.

Glad it was helpful!

Glad you enjoyed it. Ya, I don't really know what "most" people are building. When building LOB type systems, in my experience they are fairly large and often end up in less than an ideal place, primarily because of lack of cohesion and almost no concern for coupling.

👍

I think they can be a guide, but unfortunately without understanding the root issue (coupling & cohesion), they turn into "rules" and people fail to be pragmatic and understand the tradeoffs.

Focusing on 'entities' should not be thought of as 'wrong'. Derek is probably trying to direct people to focus on certain aspects of a solution at certain levels of exposure. For example, if defining a public/private API to the business, this is where consumers of this service will rather see endpoints that make sense to them, so more in tune with their 'business needs' or their 'business workflows'. So that's one level. That layer will obviously at some point need to interact with data, and maybe you have a company policy where abstracting access to the underlying data-source needs to be forbidden or tightly controlled, and therefore, engineers would need to build a mechanism to expose 'entities' that represent the underlying source, and this is the fine-grained/micro level. Generally public facing API's should be more 'capability' driven and not needlessly 'data/entity' driven. Having said all this, when you look at Microsoft D365 OData API, they have ZERO capability level API's, they are all ENTITY based, at least from and endpoint pespective the terms are all 'entities'. So I gues it all depends on the type of thing you're building, and what type of consumer you are focusing on. :-)

@@joaodasilva2175 Good point Joao. My comment was overly simplistic in hindsight. Thanks for the comprehensive reply.

Yes. So as long as your making that distinction and are aware that your logical separation is different than the physical storage. They don't need to be the same, so yes.

Often they are shared between various features, but a very limited subset that are related. Eg, Adding, Removing, Updating items, and Checking out a shopping cart all require the shopping cart.

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-DjZepWrAKzM.html and I saw this video from you, and you didn't put the part 2 😅😅, How can we compose and retrieve the data from it. If you can help me. Thanks

The example is simplistic but to illustrate that different boundaries care about different data depending on the behaviors they provide. Each boundary would own the schema and data and provide a means through an API/contract. I wouldn't integrate via the database (eg, joins).

I kind of know what you're referring to but I don't really do much of moving private to public etc. for testing purposes. Having multiple types isn't a problem as it's about grouping them together in the right place.

@@CodeOpinion Sometimes you'll have a lot of branching happening in those private. That makes testing particularly difficult for 2 reasons: 1) it might be a lot of work to setup inputs so a given branch is explored, and 2) the exponential explosion of branches. If you decouple by injecting dependencies then you can test the branches independently, avoiding the exponential explosion and simplifying test setup. The problem is now you have lots of mocks, so your tests are coupled to the implementation. So there is a balance there too. Branches often are a sign an endpoint tries to do too much, but eh sometimes you can't ask your client(s) to change their code just to simplify yours. You have to contend with the contracts as they are: full of bells and whistles, options, bools, nullables = branches galore.

Not yet!

Used as a guide they can be helpful. But if you don't understand the underlying reason they exist it turns into a pissing match. The number of times I get "but doesn't this violate X principle?" is pretty interesting.

@@CodeOpinion Totally. Context matters!

Not entirely. DDD has strategic and tactical patterns that ultimately are adressing coupling and cohesion. Almost everything resolves around them at the core.

Accurate

I'll give videos in the future with code examples.

Define one "thing". Everyone seemingly has a different definition. I'd guess most would use the "one reason to change" but think of it technically rather than business requirements, which is how I think of it.

@@CodeOpinion exactly. "Thing" here is could be business department. For example, Product in marketing department, is different than product in warehouse department. This is the kind of single responsibility where people often misunderstand. They put all the product related behaviour in the same class

My experience is it's industry wide on any platform/language/ecosystem

Why would or wouldn't you? I covered this in a video about event-carried state transfer (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-IzBEbfSg0uY.html). But generally yes if it's more reference data from a supporting boundary, then sure. However often times most folks are concerned about replicating data when it's really just for View/UI composition, which is another topic that I need to cover.

Microservices implies physical boundaries. Logical boundaries don't have to be physical boundaries

Low cohesion will lead to high coupling. High coupling ultimately makes things more difficult to change. Check out this video, see if it helps: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-wRVbHDkOMSM.html

​@@CodeOpinion "Low cohesion will lead to high coupling. " = "If the degree of how well things belong together is low, it will lead to the degree of interdependence between modules being high" If many modules are interdependent - it means that overall system is hard to change. So, to reframe this - if a thing doesn't belong somewhere firmly - it belongs to everywhere and a system becomes a ball of mud (difficult to change) if a thing belongs to a certain part of the system firmly - you have a limited number of dependencies on it and it is easier to change. I see that often the dependences are sort of bi-directional if a certain service doesn't bother to wrap the data in it's own abstraction. e.g. a details of CRM system leak to billing through sales, where sales doesn't change things. Then as long as billing gets some information, over time it starts to build dependencies on it, first accidentally and then as a lowest friction path. - it is faster to put data through the whole stack in a single format and schema, rather then create representation on each. Then it becomes that all parts of the system depend on CRM for example. So the "Ce" is hiddenly very high

My point is that if you started with coupling and cohesion, which I assume most don't, and you start with the ways to to deal with them, you don't really know why you're doing what you're doing. "I don't think any seasoned developer "thinks" about the individual components of SOLID on a day-to-day basis". I don't think anyone can agree on what "seasoned" is anymore. 😂

@@CodeOpinion I certainly agree with your point... I think that is sort of what I'm getting at. I don't think anybody can really agree with what the word "clean" means anymore. At least most people can have a relatively common understanding of what the words "coupling" and "cohesion" mean, so it makes for a good reference point