Bounded Contexts in a Facebook-Like Domain

[Joseph Ferris]

All,

I am struggling to identify the bounded contexts in a Facebook-like domain.  Below, I've provided a braindump of a lot of the high-level nouns and how they relate to each other.

My problem is that the domain is very User-centric.  It is fair to say that the User is the heart of the core domain, and while I easily see subdomains and the aggregates that would comprise it all, the only additional bound context that I am really seeing is at the bottom-left of the image.  An User is a generalization of an Account, as is an Administrator.  The role of an Administrator would allow for that person to essentially edit and delete any content, as well as dole out Suspensions for Users, as needed.  There are a few things that could be added there, as well - such as a means for various types of content to be reported, and a means for the Administrator to see what has been reported.  Needless to say, those aspects still need to be expanded on.

I am leaning towards the fact that this is simply on large bounded context, ultimately - only because I am not seeing any delineation.  Based on the responsibility of the Administrator, I would essentially have to mirror the entire core domain, and just add a couple of smaller concepts.  Additionally, there is are a lot of implied relationships that I omitted from the image, just for the sake of clarity.  Everyone who uses social networking will see them, i.e. notifications are generated by comments and reactions, as well as new messages in a conversation, or recieving a relationship request, etc.

On the other hand, however, I do want to see some level of isolation between the availability of commands that could be sent - at least in terms of making sure that the primary UI implementation (non-admin, user-facing) is not calling into administrative commands.  I could enforce this by how I package the commands, I reckon - but that is also what makes me think that I am missing something.  Perhaps what I am looking for is a Shared Kernel?  When it comes to the point of persistence, ultimately, I would likely want to have not just the commands isolated, but also the repositories.

Any thoughts?  Not sure if I am just missing something, or am trying to make this harder than it is.

Thanks!

[Ben Kloosterman]

This is how you would build a relational model... ie data focused which does not work that well for DDD .  Im no expert in DDD modelling but i normally start with some commands ( verbs) and see where they go - the blue book has quite a bit on modelling  but its more about business concepts which are weak in this type of system .  I wouldnt event try to create BCs at first , sort out your aggregates,, you can refactor them into BCs once you have more of a structure if its too big,.

Also user above is both the  user relation and the user actor  , nearly all domains have a user actor but you normally break them down into specific users eg  adminUser , Customer etc ( in your user story or actor) .   

Note in most case dont  put admin and authentication into a BC  , CRUD works much better for these , tyring to model IT concepts doesnt work.  At a guess

Admin CRUD BC

User/ Authentication CRUD BC 

Post DDD BC ( and break it up further after creating aggregates and their relationships) 

Also photos and posts are very similar  ( both have comments and reactions) so your missing a concept what this represents.  Maybe its a post and a post has a content that can be a picture or text post. 

Ben

[Joseph Ferris]

Thanks, Ben.  This is all very helpful.

Very much agree that this is not a traditional candidate for DDD, in terms of business use cases.  I have been mired in a very traditional big ball of mud with my current client for a few years, and am using this as an outlet for both getting back in touch with my creative side and for getting back into DDD after several years since I was last able to exercise the concepts.  The entire conceptual system is a bit CRUD-y at the moment, but I also expect it to grow over time, as well as increase in complexity.  No idea if this will ever become more than a bench project for me, I just want to do something other than Active Record, if that makes sense.

I have started to compose my Aggregates, and you are definitely correct around the Photo concept.  Last night, I was toying around in that area on paper, and ended up with a Photo being a specialization of a Post - not unlike how an Open Graph share could be a specialization of a Post (your typical "Share This" posts).  For the most part, I had been avoiding the concept of Posts in my mind, because that is one of those areas of unknown growth.  My expectation would be that a Post will be more of a generalization, as I would want to have some sort of extensibility where add-ins could generate Posts and create Notifications.

Starting with a single actual DDD-based Bounded Context and focusing on the Aggregates is definitely sound advice, I think.  Like you point out, authentication is a technical implementation and in the POC it is currently outside of the domain, already.  I will treat administration the same way, like you suggest.

Thank you!

[Chris Richardson]

A few random thoughts.

On Sun, Sep 25, 2016 at 7:24 AM, Joseph Ferris <joseph...@gmail.com> wrote:

Thanks, Ben.  This is all very helpful.

Very much agree that this is not a traditional candidate for DDD, in terms of business use cases.

When you say "this" what are you referring to?

The domain model that you have created is a traditional "monolithic" domain model.

And as in many domains, the user is pervasive and connected to everything else.

But that doesn't mean that you are required to have a monolithic BC.

But looking at it there is evidence of several distinct "chunks" of functionality that are possible candidates for  BCs.

• Messaging BC - conversations - ie. FB messaging
• Photo BC - albums and images
• Posts BC - posts
• Profile BC - user profile management 
• Authentication BC - users and their credentials
• Relationships BC - social graph and friend requests
• Comments BC - comments and reactions to photos and posts.
• Admin BC - kinda separate from above
• ...

In each one there is a manifestation of a user although it might have a more specific name, e.g. a Post has an Author.

Just my two cents.

Chris

-- 

Learn microservices - http://learnmicroservices.io

Microservices application platform http://eventuate.io

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joseph Ferris]

Chris,

On Sunday, September 25, 2016 at 1:22:25 PM UTC-7, Chris Richardson wrote:

A few random thoughts.

On Sun, Sep 25, 2016 at 7:24 AM, Joseph Ferris <joseph...@gmail.com> wrote:

Thanks, Ben.  This is all very helpful.

Very much agree that this is not a traditional candidate for DDD, in terms of business use cases.

When you say "this" what are you referring to?

The domain model that you have created is a traditional "monolithic" domain model.

By "this", I was contextually referring to the fact that the application is not a traditional line-of-business application.  Can definitely see how that was not too clear.  :-)

 

And as in many domains, the user is pervasive and connected to everything else.

But that doesn't mean that you are required to have a monolithic BC.

But looking at it there is evidence of several distinct "chunks" of functionality that are possible candidates for  BCs.

• Messaging BC - conversations - ie. FB messaging
• Photo BC - albums and images
• Posts BC - posts
• Profile BC - user profile management 
• Authentication BC - users and their credentials
• Relationships BC - social graph and friend requests
• Comments BC - comments and reactions to photos and posts.
• Admin BC - kinda separate from above
• ...

In each one there is a manifestation of a user although it might have a more specific name, e.g. a Post has an Author.

Just my two cents.

Chris

That is extraordinarily helpful.  My problem, I think, is that I was looking at usage scenarios in terms of the actors using the system, as opposed to the actual context of the responsibilities of the system. I was re-reading Vaughn Vernon's chapter on Bounded Contexts in "Implementing Domain-Driven Design" again, last night.  That, coupled with the responses that I have gotten here, have helped to open my eyes a bit more.  Between looking at the actual domain in the wrong way, in addition to tempering my decision-making with technical details, really had me focusing on the wrong areas.

Can't thank you both enough.  Very, very helpful.

Thanks!

Joseph

[Joseph Ferris]

All,

Based on the feedback received, I feel that I am in better shape now.  Sincere and heartfelt thanks!  I still have work to do, I know, but it does make a bit more sense now.

Next up, refining the domain and identifying subdomains, along with any missed concepts.  I'll make a more traditional context map out of what I have now, since I can actually see how these bits do relate.

Thanks!

Joseph

[Matthias Breddin]

Very interesting topic, I'm also currently modelling a "rewrite" of a current project (social dating platform) and i'm also a little bit stuck on the BC side and made the same "mistake" like you by watching more from the user centric part then identifying real BC. 

Please keep us posted on updates, much appreciate it. Thanks

Matthias