Timeline for Why is a architecture with anemic models the JavaEE standard?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 24, 2015 at 22:18 | comment | added | Andy | @Oscar agree, you would not directly expose your domain model with a web service. You'd do just as you said, with the service built on top of the domain layer just like any other client interface (GUI, command line, etc.) | |
| Apr 24, 2015 at 22:13 | comment | added | Andy | @RobertHarvey rather you can't move logic between two platforms. Logic is code, not data... unless you're going to write something that converts between one language to the other on the fly. Finally web service contracts are NOT the same thing as domain models. If you're tying those together you're asking for pain. | |
| Apr 24, 2015 at 22:09 | comment | added | Andy | @YazadKhambata the state is encapsulated in anemic models but not the behavior. when you're talking about two different platforms you're inherently talking about two different applications which are different bounded contexts. You'd connection them probably via web service but the service contracts are just service contracts, they do not have to represent the shape of the domain models the service uses to do its job. | |
| Apr 24, 2015 at 21:52 | comment | added | Andy | @RobertHarvey You don't in those cases, you end up having to duplicate the code. Anemic models don't even have logic to transfer anyway, they're by definition dumb. | |
| Apr 24, 2015 at 7:57 | comment | added | JSBach | @YazadKhambata That comment was also for you, but I can mention 2 users at the same comment ;) | |
| Apr 24, 2015 at 7:57 | comment | added | JSBach | @RobertHarvey You would have anemic models in the "transfer layer", they would be DTOs or somethink else, so you can avoid the json/xml parsing issue, but I wouldn't call them "business model". Ideally I would map them to non-anemic-models in the boundaries and process this non-adnemic-model inside my system. What are your opinions about it? | |
| Apr 23, 2015 at 2:11 | comment | added | Y123 | You are right - now reread my answer and you'll see you are arguing for me :-) | |
| Apr 23, 2015 at 2:04 | comment | added | Robert Harvey | In practice, you're going to have anemic models anyway, because having first-class objects implies knowledge of the underlying systems, and we don't have that knowledge in practice. Look at how much JSON and XML we use in web services, for example. All of that is anemic data models on systems which we know nothing about under the hood. | |
| Apr 23, 2015 at 1:53 | comment | added | Y123 | If cross platform interoperability is a none issue like if all systems are on one propritery platform then yes what you say makes sense. However in an enterprise system one has to think about diversity of communicating systems and I believe this a relatively small loss since BL is the function of the service layer in the architecture in question. | |
| Apr 23, 2015 at 1:48 | comment | added | Robert Harvey | @YazadKhambata: I don't see significant value in providing trivial getter methods, nor do I see value in a POJO computing a total price. If anything, you're passing item objects and the total price is going to be computed somewhere else. | |
| Apr 23, 2015 at 1:47 | comment | added | Robert Harvey | @Andy: How does one move logic between disparate systems? Oh, sure, if you have Javascript in the client and Javascript in a Node.JS machine, then perhaps you're working in a similar environment, but how would one expect business logic to transfer over, say, between a Java-based service and a python-based one, or even between a browser and a non-javascript-based server? | |
| Apr 23, 2015 at 1:34 | comment | added | Y123 | @RobertHarvey - I don't mind editing my last para if you could elaborate what is confusing. Thanks! | |
| Apr 23, 2015 at 1:15 | comment | added | Y123 | I am not an expert in .net so I cannot objectively compare that. However your point on making it procedural is wrong since POJO encapsulates state along with access and mutation behavior bound with it. This is not a feature of procedural language. Again when one says .net 'enforces' the BL has an issue since the client in question in an enterprise software may not belong to the same platform example a web client using JavaScript or a Python client running on Linux (no mono). Let me know your thoughts. | |
| Apr 23, 2015 at 0:33 | comment | added | Andy | "Contracts should define the expected structure of inputs, outputs (and exceptions) not the business logic.". interfaces are contracts (and in .net Code Contracts lets you define real DbC contracts which are enforced), not objects. The anemic models you describe effectively revert OO back to procedural programming. Pojos which are designed around being serializable aren't domain objects at all, models should not be anemic, the should be the source of truth for whatever they represent. | |
| Apr 22, 2015 at 23:43 | comment | added | Robert Harvey | Your last paragraph doesn't really make much sense, but the rest of it does. | |
| Apr 22, 2015 at 18:59 | history | answered | Y123 | CC BY-SA 3.0 |