Timeline for How to handle events representing cross-domain knowledge
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 22, 2024 at 11:09 | vote | accept | Simon Geard | ||
| Aug 21, 2024 at 12:46 | history | edited | Christophe |
edited tags
|
|
| Aug 21, 2024 at 7:52 | comment | added | Simon Geard | @JimmyJames Sort of, though as I said, this is more of a learning exercise expressed through a real business domain, rather than an immediate work-related problem I'm trying to solve right now... trying to understand how others, particularly DDD proponents, would approach problems of this nature. It's why I keep distinguishing between what I'm willing to do as a pragmatist, and what the idealist answer might be. | |
| Aug 20, 2024 at 20:58 | history | edited | Christophe |
edited tags
|
|
| Aug 20, 2024 at 14:47 | comment | added | JimmyJames | There are going to be some inherent dependencies between your domains because they are part of the requirements. I kind of got the sense that you are wrangling with an existing solution and how to untangle it (I've been there.) You might want to step away from the technical details and whiteboard things out. Maybe work with a business SME. Once you have things described in the abstract, then come back to the software. | |
| Aug 20, 2024 at 9:33 | comment | added | Simon Geard | Oh, and for perspective, I work on an monolith of some millions of lines of code that's been growing and evolving for decades... So at least in part, this question is me thinking about how to put some dividing lines through what's currently an exceedingly-complex "omni-domain". | |
| Aug 20, 2024 at 8:46 | comment | added | Simon Geard | @JimmyJames Maybe that's where I'm going wrong in worrying about that, but the concern was two-fold. One is that "PleaseCreateATransaction" doesn't sound like an event associated with the Billing or Payment systems... it's more of an instruction (but maybe that's okay if we call it a "command" instead of "event"?). The second is that it implies a strong degree of cross-domain knowledge (Billing and Payments need to know what a Transaction is)... and pragmatically, I'm okay with that, but this being a learning exercise, I'm trying to understand the idealist perspective on the matter. | |
| Aug 20, 2024 at 8:38 | comment | added | Simon Geard | @Christophe Exactly so. As I said, this is a simplified learning exercise based on a domain I'm familiar with — but these are definitely different systems. "Accounting" is pure book-keeping... in reality, it would be quite closely linked to the company financial system. "Billing" is hugely complex but focused on figuring out how much to charge the customer for the services they're using... and yes, lots of stuff around pricing, rebates, processing usage measurements, contracts, etc. | |
| Aug 20, 2024 at 1:25 | answer | added | Flater | timeline score: 3 | |
| Aug 19, 2024 at 22:40 | answer | added | Christophe | timeline score: 4 | |
| Aug 19, 2024 at 15:31 | comment | added | JimmyJames | "but it feels inelegant at a design level" Can you elaborate on this? What problem do you see with creating a transaction (maybe credits and debits) along with a reference to the associated invoice or payment. | |
| Aug 19, 2024 at 13:02 | answer | added | Ewan | timeline score: 1 | |
| Aug 19, 2024 at 12:36 | comment | added | Christophe | @RikD In a small business, the accountant may be in charge of the billing and the payments. However, both billing and payments can be extremely complex in medium and large companies, as it involves many operational details, like unit price, price conditions, rebates, payment mechanisms, etc... that have their very specific language with very specific terms that are not part of traditional accounting. | |
| Aug 19, 2024 at 11:09 | comment | added | Rik D | Bounded Contexts are language boundaries. When domain experts use the same term that has a different meaning in their context, you stumbled upon such a boundary. That doesn't seem to be the case here, this could well be the Financial Bounded Context that knows all these concepts. Either way, the DDD pattern to guard Bounded Contexts from terminology pollution from other contexts is the Anti-corruption Layer pattern (ACL). | |
| Aug 19, 2024 at 10:57 | comment | added | freakish | I think your accounting component should not be so simple, and it should actually know what invoices and payments are. An alternative would be for those other systems to emit "transaction" events, which moves the responsibility of understanding "transactions" to two other systems. Doesn't seem to be worth it. | |
| Aug 19, 2024 at 9:07 | history | asked | Simon Geard | CC BY-SA 4.0 |