Timeline for How to model Business Objects depending on use cases?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 26, 2020 at 15:19 | comment | added | Christophe | I have updated the first bullet, because the way it was formulated was definitively too ambiguous, considering the exchange of comments above. | |
| Aug 26, 2020 at 15:17 | history | edited | Christophe | CC BY-SA 4.0 | added 441 characters in body |
| Aug 26, 2020 at 14:59 | comment | added | Christophe | @RobertBräutigam Moreover, maybe you are extremely gifted and always immediately come with a perfect domain model and a perfect split by applications. But not all of us are as lucky, and this is why I propose a prudent approach, which leaves some more doors open ;-) | |
| Aug 26, 2020 at 14:55 | comment | added | Christophe | @RobertBräutigam you seem to think I am conflating whereas I think you are missing something. My position is that if several application are working with the same concept of pallet, and are expected to provide a consistent experience, it can be a huge benefit not to reinvent the wheel in every app. If it appear up-front that the domain can be split by component (e.g. by app, or one subdomain per microservice), your approach is just fine. However jumping to that conclusion is not always the best option. | |
| Aug 26, 2020 at 14:42 | comment | added | Robert Bräutigam | You are conflating two things: physical objects and model/conceptual objects. Multiple applications may deal with the same physical object (like a pallet or a customer), but they should not share the same concept, i.e. behavior, i.e. code. Evans even argues for keeping the context clearly separate even inside the application if there are multiple contexts in it. So, you can have more than 1 domain in 1 application, but you can not share 1 domain to multiple applications. If nothing else, that would double you maintenance costs right there. | |
| Aug 26, 2020 at 13:09 | comment | added | Christophe | @RobertBräutigam Bounded context are not meant to keep domains private to applications, but to separate distinct domains. If you have a warehouse domain, some applications may deal with inventories, other with picking items, still other with optimizing physical movements, some for controlling warehouse robots. It’s all about pallets, materials, storage locations and incoming and outgoing deliveries. If you decide up-front to have 1 domain per application, you have decided up-front on the architecture, not necessarily the leanest one. | |
| Aug 26, 2020 at 12:32 | comment | added | Robert Bräutigam | I only know the usual "business applications" (banks, retail, utilities, etc), so there might be areas I haven't experienced where the above is needed. However, even in DDD which you cite, "bounded contexts" are introduced exactly for the reason not to share "domains". Also, as mentioned, I don't want to address "presenting, logic, persistence" separately, because they are closely related and coupled, i.e mostly change together. The Layered Architecture makes applications less maintainable. | |
| Aug 26, 2020 at 12:13 | comment | added | Christophe | @RobertBräutigam This being said, it’s your right to disagree and DV, and I appreciate the opportunity for clarifications, but it would be more constructive to provide your own answer so that we can see if there is at least some common ground (or if just must disagree as strongly as you) ;-) | |
| Aug 26, 2020 at 12:05 | comment | added | Christophe | @RobertBräutigam Let’s clarify: the application adresses several concerns, such as presenting, business logic, and persistence. Decomposing these in different layers (or cores, depending on the architectural layer) makes only sense with the right focus. Moreover (at least in my area) same domains are often shared by several applications, each specialized on some tasks. The issue I see everyday is that sometimes people build specialized domain that inappropriately represents what it’s supposed to represent, and that are difficult to upgrade because completely coupled with application logic. | |
| Aug 26, 2020 at 11:01 | comment | added | Robert Bräutigam | I disagree with every one of your points here, the most with your first point: "you need to separate concerns: the domain is not the application...The application just provides functionality...". "Just"? The application's main purpose is to provide that functionality. This can not be an afterthought. There can be no model independent of how it's used. Separating the concern to provide useful functionality from its data is about the worst thing one can do. | |
| Aug 25, 2020 at 14:08 | history | answered | Christophe | CC BY-SA 4.0 |