I’m in the process of splitting up a monolithic application into bounded contexts.
It’s hard to relate to a lot of what has been written about ddd and segregating according to business capabilities, teams, etc. We are an ISV selling software that’s run on customer premises. I’m pretty much the only developer doing backend. There are no domain experts other can current and potential customers, and they differ a lot. We got everything from really small operations where one person handles pretty much everything, to public organizations that are very divided.
Domain is selling tickets, handling entrance, POS, etc.
Some things are given, like having a bc for tickets, invoicing, sales, stock etc. But there are also some things that really fall on the fence, like giftcertificates. Do they belong in sales or in their own bc? (which would pretty much just be one aggregate). They’re both a product and a method of payment, and are pretty much in the confines of sales. But so are a lot of things…
My motivations for splitting it is primarily to isolate and be able to choose implementations more freely, rather than having one ‘right way’. (theres definitely something to be said for consistency, but as this will be a system with many years development and lifespan, I want to be free to use different approaches/pattern without feeling to the need to rewrite/update existing components). And to keep my sanity, being able to focus on one bc at the time.
So what factors can I look at given the circumstances? Gut reaction? J
/Peter
--
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.