AVOID Entity Services by Focusing on Capabilities 

Adam Smith's principle of the "division of labour" applies to software just as it does to business and the economy. If it makes sense to hire different people to do shipping than those who do pricing, it will probably make sense to separate them in software as well. Great video, Derek! 👏🏼

I like to revisit this. It has been useful in reasoning about what a complex system can look like. There is also the video about syncing data using integration events: when you for instance want to store the Product Name in each service, but yet keep them in sync. Some would hesitate to do this. "It is bad practice to have duplicate data!". Well, it depends. Can you manage it? You totally can. I have an Identity Service that holds Accounts and basic User info. Then there is another service that holds Items that have been created and edited by some User. Instead of having to ask the Identity Service for the User's First Name and Last Name every time, I create local representations of Users in my Items Service that are controlled in response to events from IdentityService. As a consequence I can store relevant data connected to a User locally in that service.

Excellent video mate, I spent a good week or two going into a tailspin trying to implement DDD but without releasing I was just trying to apply the patterns to a data-driven mentality still. After watching this I was able to finally make it all click together. Every resource teaching DDD to newcomers should start with this!

Great video! I've been trying to teach this approach to developers for over two years. For people with a CRUD/ORM/Entity mentality, this higher level concept is really hard to understand. But I don't know why. Now I can give them a link to this video. Thanks.

I like the explanation. One way to think about the initial Product example is to ask yourself if the product should keep track of its quantity.

I was the one who asked about this in the discord ;) I'm really appreciate for this video

This video is really enlightening, thanks Derek! I would love to see more practical examples for this idea.

Great video. Your example section reminds me of how I have recently started challenging my own opinions of how products should be represented in software. I started researching what a product really is and finally came to the conclusion that a product is just a marketing/sales wrapper around a tangible good. Once I started separating the tangible good from the marketing/sales wrapper, my system became easier to maintain and extend. This was incredibly important when I started getting business requests for products that have bundled tangible goods that have one or many fulfillment strategies (physical shipping, digital download, software access, etc).

But how would you actually store that data in a Db? If you have the same property in multiple entities, like Price, and you update it in one, how do you ensure all the other entities get updated as well? Does your DB schema match your domain model or is it different?

Love this one! Great the way you refactor AWAY from entity/CRUD-centric service boundaries (based on database schema and noun-verb analysis) and towards a model that uses behavior and business language to model what the boundaries should be around "pieces" of a Product. Decomposing those pieces of data around behavior reveals what data is highly cohesive and needs to be grouped together b/c it's changed together (aka, transactional consistency). Someone at Particular software put it like this (and this is para-phrasing): "Often, you'll find you service boundaries cutting right the the middle of your entities". Some comments I've read here show confusion around transactional consistency across all boundaries for a Product, you like you pointed out, you can't have that. You can only enforce transactional consistency of the pieces each boundary owns, and the rest will need to be eventually consistent. One concept that might clear this up is that only one service can logically own the concept of a Product. In this case, what and where is the inception/creation of a "Product" into the system you're modeling? Catalog, Warehouse, etc. Once you identify the true owner of a thing, then that boundary becomes the authority of that thing... the rest of the boundaries that rely on pieces will get those pieces in an eventually consistent manner.

Amazing video. The only thing I'm missing here is elaborating on the data shared between services and possible mechanism to solve this issue. For example the dimension and weight of a product may be important to the following services: - Catalog Service - dimensions and weight could be important to the customer - Shipping Service - dimensions and weight could be used to accurately calculate the shipping price - Warehouse service - dimensions and weight could be used to automatically find the best place to store the product in the warehouse

I like the explanation but I would like to see a practical example of this. What does it mean also for reports and general data mining in this paradigm?

awesome ! really helpful! thanks

Great video! I learnt something new and VERY useful. Thanks for sharing, you earned a like.

Thought provoking -- love it!

CRUD driven services are easy to just start writing, I believe that's probably why they are so prevalent.

I wish this is what i were taught. I've been stuck in a very CRUD like way of thinking since passing my exams. Thinking capabilities gives a much better view on the domain we are within.

Totally agree. Nice video!

it is about object oriented and monolithic thinking - even in oop you should separate based on behaviours/capabilities instead of building a super-base class ... good example and explanation - thx!

Another great share of knowledge, at the beginning, I was ... what!!! but I could understand and agree

Another reason for the love toward entity driven architecture is that when splitting the monolith, it looks easier to keep the same DB structure and just add some microservices on the top of it. And you end up with a distributed monolith...

Thank you

I really like the format you're doing here. Particularly that it's opinionated and reasoned well. I don't always agree, but I'm always interested in what you're saying...if that make sense.

I got some feels of interface segregation here.. thank you for this sir.😊

How would that be done in spring boot? Multiple entity classes to one table?

Your channel is amazing, man!

How would you make sure that all these bounded context have the same SKU? Would you keep a cache in each BC? Do you make one owner of the SKU for example catalog or do you have different SKU's for basically the same product?

Wow, in just 7:30 minutes you saved me a lot of time. Just to make sure I understood correctly. I can have a "Product" locally, AND have separate ProductService (or different; it would handle concept of Products in a more complete manner) and just keep them in sync (ProductService -> local Product table), correct?

It woul be nice to compare the differences between data and capabilities from the API (Rest) perspective and how this methods are mappeed

I really enjoy your channel, thank you for your effort. I have a question about properties that needs to be shared. For instance the name of the property needs to be shown to the user when they are updating the product info, the cost and the price and when viewing the quantity on hand. Does that mean that the catalog service must be called each time to get the name, or do the other microservices keep a local read-only cache of the name?

Hey! Thanks for the nice clip. When it comes to Rest API, I think its methods are somehow CRUD centric(GET /POST etc..), so it is hard to keep the official naming convention of it. I think putting verbs on the Rest resource is more natural in behavior-rich design. Do you have any opinion about it? :) Thanks!

Gosh, this channel should have 10MM of subs at least, all B.S. content about software design out there are massive misleading, whoever has participated in a couple of real world projects can confirm that what this guy is exposing it's truth. Data Centric model works fine until it grows and becomes a big giant monster that no one is capable to work in efficiently, an endless source of frustration.

This is awesome aproach, for those services you mentioned (AdjustPrice, ShipProduct, ReceiveProduct, UpdateProductInfo), if I were to have HTTP REST APIs to expose these services, what would be your approach for naming them? PUT Product/UpdatePrice, POST Product/Ship, POST Product/Receive, PUT Product/UpdateInfo ? any recommendation?

Critical when creating loosely coupled micro services!

I wonder how do you design the API to match these actions? You do Rest and then translate? Or are there any other conventions that are more suitable?

the point is the interface.

Awesome series. Much appreciated! It closes a long-existing gap between those who *want* to learn DDD and those who are able to implement DDD. I'll stay tuned for more episodes. One question. You are going from a "badly" implemented data schema with loads of dependencies over a badly implemented service approach (Entity-driven) to a good service implementation (behavior-driven). It really makes sense how you organize services and their methods. Question is now, what would you suggest the data schema should look like, i.e. the required tables. Are you suggesting to match the database tables the new microservices (several product tables for sales, purches, etc.) or is it "ok" to leave the schema as is. I suggest the former but I feel you didn't say that explicetly. Thanks, man

Derek, what if u need to show all catalog, prices, and inventory count on a product table in the same web page? will u still use this capabilities approach ?

Underneath this there's the idea of a bounded context in the scope of a microservice.

Awesome

Hi Derek, While I agree with you. I wanted to know your opinion. When having a microservice per capability not per business model, this usually leads to have a microservice that is not micro anymore. It becomes more of a service in a kind of SOA environment. What are your thoughts onthat and how to prevent that?

I like the idea of it but having a really hard time applying this to our real world scenarios. I feel like my aggregates are trapped into CRUD stuff. Our application is heavy data focused (we need to maintain a lot of data which just is data that we need to store), which is about 60% of the application. But we also have 40% of actual functionality and behaviors. Though can't seem to translate it to our domain model. Would love to see more real life examples.

Instersting, but how do we manage the very first product , and its Price? Perhaps with one method on Sales with the first date for that product ?

Interesting video I have question. What If you want to search for product with name and "in stock" and also retrieve price. Should you have another microservice (for example search service) with seperate db that has that data side by side and duplicated? Or should I call catalog service, sales service and warehouse service to get that information just to search?

great video. tks. how would you organize the data layer drived by this design by capabilities?

By this approach, Won't there be too many tables or in the end it will be nearly the same as CRUD based design? Also, consider if we just need to show up quantityInHand while displaying product information in the future, how to handle this?

Just 1 quick question: for shared properties like product SKU, how to keep it consistent across services?

Wish you would flesh out these kinds of examples more in code.

I always get confused what would UI would look like for product. As data will reside in different bounded context. How can it be updated in a single transaction.. I.e For creating product Ui would look like as follows: Name Desc Cost Price. Now when user saves the form.. the SKu will be created at UI level (guid)and data will be sent to its respective Context.. what if Sales fails to save .. so there will be a catalogue without Price.

How does such an approach work on related data? Let's say I have items, and those items have posts related to them(users created posts), other users can like these posts. How does such a system get decomposed into a capability oriented system, rather than CRUD based approach

how to get out of CRUD mentality?

does it mean that now you have to created 4 tables instead of one in the database even though you're running a monolith architecture? or is it one table where different modules are concerned about different properties of that table. and yeah, that's a type of question that only data centric person could ask :)

To keep with the example from the video, let's say we have a ProductCatalog microservice that owns the SKU and general product data, a warehouse microservice that owns the stock information and a sales microservice that owns the pricing information. You have shown in other videos how a task-based UI (in contrast to CRUD) for this would look like, but how would this UI work when you are creating a new product instead of editing an existing one? You'd have to create the product base information first, then add pricing and stock information afterwards. This is pretty awkward and leads to a situation where the "product" is in an invalid state, because it has no stock or pricing information.

How should data be handled that needs to exist authoritatively, but is logically required for multiple processes? For example, suppose the system has the requirement that it may only sell products that are on hand. Should QuantityOnHand be an attribute of sales, or an attribute of the warehouse? Suppose we want to add a new capability to the system, such as reserving inventory when none is on hand. Do reservations become a capability of sales, warehouse, both, or a new service altogether? It would be helpful to go through a more complete example and discuss some of the common issues that come up with this capabilities centric framing.

Again awesome content! I understand that we should not focusing on CRUD instead of behavior... So should we also splitting that entity in database according to its behavior...? If yes then, Is this also true even when that project is not in distributed(microservices) architecture?

But I need to provide my services. :(

You're hired, you can be the design manager and yell at my programmers now :P

Hmm, good insight but I am not yet 100% convinced to be honest. I never liked the "Let's have a microservice for every single piece of data" structure to begin with and never really followed it in that respect. However, this sounds like you'd be building a microservice for every "actor", to which I also don't fully agree with. To me a microservice could have more than just the single piece of data or single actor. It can be a combined effort of multiple pieces of data and actors, as long as the link between them is direct if that makes sense. For instance a customer and his cars owned could be a service to which both admins and customers connect (talking backend service). But the car and its parts could be a different one as long as it logically makes sense to split them up. I'm not really sure if I am making myself clear here either.

But why? What does this afford? You say less decoupling but what does that mean in ROI. I mean this all works just fine but I don’t see the advantage over Entity based as Entity based is straight forward to find things. Why rebuild the wheel if it isn’t better, just different.

There's no reason these idiomatic capabilities would not be right at home atop a entity service layer. AdjustPrice just takes a dependency on your 'Product' entity service. Tell me, how would you handle AdjustPrice without an 'entity service'?

Personally I would never design my DB to have quantity and price on the product entity to start with. Reporting would be ass if sales wants a rundown on products sold before and after a deal or a price increase. new stock would have new cost pricing that affects margins if retail pricing stays the same etc. But that has nothing to do with the video and Im just bored. 😜

Your approach do not follow Object oriented programming. Can you slip yourself into 2? This approach will accommodate a whole lot of repetition, at the long run will be very difficult to manage. Loose coupling can also be achieved in Service oriented design which is to sync your dev into using more composition/aggregation. I think it is futuristic but still need more juice.

Simple data model but massive schema 🤣

You missunderstood the sense of entity servcices. What you are describing here are usecases. Entity Services have one job: make sure each instance of an entity issssss valid and follows the business rules.