Driving forces for bounded contexts

[Peter Hageus]

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

 

 

[Chris Sampson]

You can always try your idea for a seperate BC and if too much data is flowing over the boundaries then change them at that point. So kind of feeling your way through it maybe your only choce without domain experts around.

--
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.

[Tom Janssens]

As most of us can't predict the future, I'd suggest splitting things when it hurts/will hurt, not sooner.

Op maandag 6 juli 2015 10:08:04 UTC+2 schreef Peter Hageus:

[Peter Hageus]

It hurts now, that’s why I’m splitting it up :)

It seems like it pretty much comes down to moving a few inter-aggregate processmanagers to inter-bc, and having a look at how much they have to know about the internals of each bc and draw the lines from there…

/Peter

[Tom Janssens]

Ah :p

Think about different kind of things that can define BC's:

- Organisational

- Language

- Transactional

- Life-time

- Life-cycle

- Dependencies (Don't forget risk mgmt: if this BC is down, will my other still work?)

- Personas

- Documents

- Security

- ...

You catch my drift: look at it from as much different kinds of POVs as possible. Usually, when I find a good separation for the boundaries, all the boundaries seem to match the criteria

Op woensdag 8 juli 2015 09:48:38 UTC+2 schreef Peter Hageus: