[[Ian Cooper]] https://youtu.be/IXGTpwHcY7M?si=pBuEUY-ZRr0zDcYu&t=931 > A big mistake in Service-Oriented Architecture was that they chose to use the object oriented paradigme to define how we partition systems. Making the system very entity focused. > The problem is that much of the business logic eats it way up into a gataway layer With a focus on entities the systems need to evoke many of its "entity services" to facilitate a single workflow https://youtu.be/IXGTpwHcY7M?si=fexypa3wgTv_0izy&t=1000 > I think there's a danger with kind of this model uh of event storming it's leading us towards focusing on Aggregates it's very useful but I would tend to use it more to describe one model rather than look for how many models https://youtu.be/IXGTpwHcY7M?si=W8Xm2u6NpHlftM9f&t=1018 > responsibility the main one I want to talk to you about so uh Nichol just said this big quote but effec what it's saying is you need to focus on business processes processes are formed in different steps activities of tasks and different systems excuse > process is usually a verb noun combination that is something your business does like make lunch or prepare a bill. Capability tends to be the thing in your business that actually does that process ![[processAndCapability.png]] Quotes [[Michael Nygard]] [[Focus on Behavior Instead of Data]] ## Domain storytelling ![[Activities-that-belong-together.png]] Activities that belong together are a good candidate for partitioning of the system ## Not done yet doain storying because it's brilliant um so domain storytelling is a bit like a sort of modern version of use cases so what happens is we draw a model and it says an actor performs an activity on a work item and we model everything that's happening so here they're doing this is a classic example from that from their site which is about booking effectively a Cinema ticket so it says a customer ask reservation so the activity in a work collector right and effectively the cashier recommends available seats to the customer so basically an actor and a work item another actor involved as well I confirm what the seats are to in a work item and effectively get a reservation number and effectively part of this flow then there's also this flow over here which is actually me looking at screen plan to see where the tickets are and get reservation numbers right so this interaction actor and uh activity against Bally a work item are key is to keep modeling everything in terms of that it's very similar to how use cases work this ticketing system is an act as well all right so computer system in the representation of an actor you can model at different levels uh quite high level what they call course grain or quite low level and fine grain so you can choose to go into the depth you want but this effectively is the modern version of use cases and it's brilliant uh and what you can do there is say okay uh activities that belong together from an actor's perspective tend to be reasonably good partitions of the system right so one here which is about booking probably to me and one here which is about seating so another way you can think about finding relevant partitions I spend a lot of my time in the past focusing very much on this model is being most useful I did we did do event storming but tend to try and keep that to be more than a single model um but of late I have found this is really useful uh you can generally involve a really broad audience in one of these conversations uh and it's this gets a little bit to um it's very useful for industry but it's a little bit of a we misusing the tool in a way to do partitioning this is kind of my current favorite but it probably requires a whole separate talk at some point for you right I have about two minutes for questions so you better be fast slack okay didn't mention strategic design at all I me you sort of implied it but responsibility is is is strategic design but then you talk about the reusing object you know um taking a concept out of one not reusing it everywhere reusing the same concept in different subdomain rather than trying to reuse the same concept yeah so responsibility in L and knowledge bases and ET come from strategic DDD um I think the trouble is responsibility bit I think is right which is to why I talk about modeling by responsibility I think the layering thing is is not great um I think it leads to um perverse system designs which don't really help because Lear s SOA has never been a good idea um uh so I I think there's the hints of what you want to do but I I wouldn't apply responsibility layers I'd be very cautious about um uh kind of knowledge levels as well unless I have a specific system need to use that so I don't think it gives you a lot of help I think it I think there's bits that are related to it but I don't think it gives you a lot of help actually figuring out how to do politicians strategic the biggest th ution uh strategic designs bounded context and context mapping are very useful but they don't tell you how to find the boundary contexts I think one of the things is that uh the DDD book is of its time and it assumes that you are steeped in the culture of its time it assumes that you know about use cases you've read wor brck object design and know about you know CRC card design Etc I think for a modern audience it doesn't provide so much because you you're out of that context in those areas when we speaking about laring here are we talking about laring in terms of you talk about laring by responsibility right so you're talking each ler like a business layer presentation layer or are we talking about no so basically it's talking about dividing up layers of responsibility in the organization so what it suggests is that um uh some uh in in a business you may have say an operational level which essentially looks after a level below that and you never talk up the operational level but the operational level governs of things happening at the layer below and it's a it's an arure yeah so each one of those things in those layers effectively is a combination of some Aggregates and services effectively the modules that's clustering together and say that lives together in that part of the layer um I think so like I say I think the idea that he's focused on there which is slice things up by responsibility is probably true but I think the layering idea this thing uh can only talk this way to this thing is I think unhelpful much as it has proven to be a little bit in terms of our individual software design that overemphasis on layering isn't as helpful as people think like the last slide about was storytelling I have a question about the uh cashier on the border of two context any insights about how to model that entity or cashier itself because from one perspective as properties from existing yeah so I think it would a little bit depend on what I was doing if I was building a system where there was um a physical cashier who you're meeting in the front of house essentially who is looking at a seating plan I'm not necessarily modeling them I'm modeling what their interaction is in reality um but if it's an automated system that I'm building where I want you to talk to a website where the cashier is effectively a computer system and essentially what you'd have to have is well what do you have what is what is this thing it's probably a service that says I've got some capabilities I can recommend something but based on what I see here so probably I'd move it over here be something that it talks to but yeah interesting question but I'd say probably belongs over here and it's through the recommendations to the customer who is effectively tackling to set the website ores yeah it could be yeah yeah this is the partition how it would reflect on the teams is it like the team yeah that's a good question it dep I mean there there are different theories about how to approach this right so a kind of strict micro service Dev opy model would say these are two different teams if I'm in a team topologies world I might ask well do they have different cognit is there cognitive load enough that um I two teams I could one team own both of them Etc so a little bit it is various theories about this exist um I would say probably if these two things Tau to each other a lot I would avoid making it one team because one team would tend to coales them together so I tend to make them two teams that the the natural fact that the teams had to communicate meant the boundary would remain in existence that temp my gut but that's just an opinion right you first and then I'll come to you and if we go I value that's is easy was easy to understand yeah so one one of the big advantages of this certainly for vent driven systems for example is you have clear handoffs and paralyzable process steps so that makes it much easier to basically turn that into a system design back to what you said about sear why why well I mean I think essentially the question would be why are we broken the PA in the first place if we're GNA let team put them together again right um so usually the problem the reason we we want to separate these two things would either be because the load on one team was too much for them to basically maintain app or um because we felt that uh the work here was sufficiently different that we weren't going to get the result we needed in terms of two teams trying to think about these two different problems so sometimes you can find that a team two these two problems uh we we know that effectively we need this to be separated but they'll take shortcuts um so it may just be that that we don't want them to merge together because we think that by separating them we'll get a better design um which can happen right I may think that uh getting this team to focus on how the screen plans and reservation numbers work in isolation from this may produce a better model because I won't be too influenced by that model right but yeah I do agree there is an argument that says if one one team owns both of them and they smooch them together it should have been one model originally in the first place yeah are these two regions uh clear cut separate I mean aren't there shared components between the shared services could be so that would be a third thing or is it so I mean obviously there are different ways of us responding to what we've discovered right and so typically you would have a conversation and decide what what does this mean right so there are different ways we could imagine that having gone to here we would slice this up right so I think effectively that there is this ticket system here right which essentially says I know about seats I know about plans for a screen and effectively I have a system for reserving the seats inside that um uh in that screen I may know things about maybe one of the best seats different pricing Etc right that's one set of domain concerns that I might think about this one is much more about customer effectively interaction it's about saying hey um you put in your what what time you want to see something um I will take that as a kind of sort of parameters I will ask about the available seats you'll then basically talk about interaction so more of a state machine driving the interaction of the customer purchase right so I I would look at that but that's only my initial reaction but your opinions is just as valid as mine in in arguing about what this looks like and say that feels like I'm building a state machine all around the customer interaction this feels like I'm building something that's all around allocation of seats we might argue either way right we might argue that's one thing right we might argue that's two things um we could we could get into that debate I I don't think the purpose of this exod tonight is to successfully uh agree how we're building our Cinema system uh I think it's more useful to understand um from this model we can in theory think about this uh question which is activities that belong together from an actor perspective can be thought of as potentially being a candidate for a bounded context so I think from the perspective of customer making my reservation is a quite separate set of activities to from the point of view of theet in system to allocating seats right that's just my but but I want to be clear that's just my perspective yours if it's different it's probably equally valid and we'd have a genuine design meeting to look about those insights and build whatever we thought was correct right some people were saying we don't need complex just be one system yeah it could absolutely be one one rather than two yeah that's why I like mind maps because then we make no assumptions we're not drawing little screens or not drawing any kind of tick ma or something we're actually going well what's that's the big picture and then we find what the what the subes are from the moment the business definitely I mean that could be it's not one I'd consider but yeah I guess that goes back to more having a conversation uh as a strategy which is kind of where we are with the kind of classic evic Model right