Lesson 191 - Identifying Components: The Entity Trap

In Lesson 190 I talked about the difference between an logical and physical architecture. In this lesson, I demonstrate an anti-pattern called "The Entity Trap" when identifying logical components and creating a logical architecture. I talk about why this approach is bad and the negative consequences of architectures created using this technique.
Lesson 190: www.developert...
Software Architecture Monday: bit.ly/3dadEe3
Head First Software Architecture: amzn.to/3VNFI0o
Fundamentals of Software Architecture: amzn.to/3rgFLjY
Software Architecture: The Hard Parts: amzn.to/3BjMMF2

[@dimitrikalinin3301]

Thank you for this great video. This is definitely a huge topic worthy of a whole series of videos. I find it particularly fascinating how to slice a system around use cases, not entities. Also, the difference between entities or aggregates and value objects, and the principles we need to follow to design a balanced architecture are incredibly interesting. I look forward to more content on this topic!

[@markrichards5014]

Thanks!

[@HKCS-yn5nc]

How do we handle the case in which different unrelated entities use a common function, if we don't place the common function in a helper class?

[@markrichards5014]

There's two ways you can handle those situations: the first is to assign the function to a likely component (in which case other components needing that functionality will be coupled to that component). The second is to create a shared component containing that functionality (being careful about the name of such a component).

[@BlindVirtuoso]

Thanks, Mark. This is excellent one. What about "service"? ticket service, customer service, etc?

[@markrichards5014]

Admittedly, I sometimes use "service" in my physical architectures at times. For example, customer profile service, ticket creation service, and so on. In service-based architecture (see lesson 163) it is pretty typical to do what you are suggesting because those services are DOMAIN services.

[@BlindVirtuoso]

​@@markrichards5014 Yep, domain services are ok, but sometimes folks fall into entity services

[@MohamedKamal-wd8hx]

What about making core business entities top level directories and under each entity there will be one directory for each specific responsibility?

[@markrichards5014]

Sure, that would work!

[@mahdi5796]

Thanks a lot. Please have an option that I can get you coffee or donate you something as a form of gratitusw; because I learn a lot from you.

[@markrichards5014]

🙂No worries - I'm just happy to contribute something back to the community in which I learned so much from in my career.