1

Sample architecture

Recently I started to learn Clean Architecture implementation. Now I'm stuck on the way to create my entities and create the between them. It's suggested in uncle Bob to have entities in each Domain. I can agree with that. But considering I have a blog, and want to design these two use cases: "Create a Post" and "Authenticate User". For me these two actions are in different domain (Auth and Blog, for example). How to design my architecture in the right way to do this ?

  • Having User and Post entities in Blog domain? So what about Auth domain, which also needs User entity?
  • Having only Post entity in Blog domain? Then how to make the relationship with User?
  • Having User in Blog domain and Auth domain, then Post only in Blog ? So how isn't a code duplication ?

Here my questions. If someone can help, I'll be very grateful. Happy sunday. :face_holding_back_tears:

Eternal Learner
  • 21
  • 3
  • 1
    I think there's some more fundamental misunderstanding here - domains are "knowledge boundaries" -- if your Auth domain contains a `User` then that will be different to the concept of a `User` inside your Blog domain (different representation, typically with different fields, constraints and relationships, and a different purpose, managed independently of each other). Any relationship between them may be based on some kind of more globally unique reference/id, but otherwise they would generally not be considered as duplicates because they exist inside within different knowledge boundaries. – Ben Cottrell Feb 26 '23 at 11:25
  • Oh! Obviously I didn't see things in that way. But yes, this is probably right. Thank you. i want to confirm something with a new example. Considering the case I have Post and Tags entities. I can "create a Tag when I create Post", but also I can "create a Tag" by itself. Do these useCases share the same entity as it's the same domain ? – Eternal Learner Feb 26 '23 at 11:32
  • I think the example is a good one, and a common occurrence which is easily relatable to a lot of real-world examples. To give one specifically - you only have one StackExchange identity that you use to login here; it's a globally unique account across the whole StackExchange network. Yet each separate SE site has its own 'user' data specific to that site (e.g. posts/reputation/comments/etc are clearly presented separately depending upon which site you visit) - I don't know the SE implementation but would assume each has its own DB, each with its own 'user' data for that site. – Ben Cottrell Feb 26 '23 at 11:45
  • ^ Assuming 'post' and 'tag' are both inside the Blog domain (knowledge boundary) then it'd make sense they would be related to the same `User` in the Blog DB. Again, using StackOverflow as an easily-relatable example, each separate site here appears (to the outside world) as being its own separate domain and knowledge boundary, likely with its own DB. I'd expect any posts, tags, users and comments on SO to be within the same physical database instance. (And not in whichever database handles the 'global' StackExchange login/identity management) – Ben Cottrell Feb 26 '23 at 11:54

1 Answers1

2

An user in an authentication context is not the same as an user in a blog context. Eric Evans calls this bounded context in DDD.

Martin Fowler gives a good overview about bounded contexts in his blog post.

Bounded Context

Martin's example clearly shows that a Customer in a sales context does not have the same relationships as in a support context.

The same term means different things to different people and therefore has different properties and behavior.

Think about what would happen if both contexts use the same Customer. Then this one Customer class would accumulate all properties and methods that are needed for all contexts.

You will recognize this problem when you implement the repositories. Since a repository is used to retrieve the entities it must retrieve all of it's data. If you only have one entity for all contexts the repository must either retrieve all the data even if it is not needed for a specific use case in a specific context or it does not initialize all of the data which might lead to unexpected behavior.

So whenever you face the problem of loading a lot more data then you need, you probably have problem with bounded contexts.

Of cource there is a relationship between the sales Customer and the support Customer, because they represent the same customer. Data synchonization between bounded contexts can be done using an event mechanism.

René Link
  • 48,224
  • 13
  • 108
  • 140