Doorgaan naar hoofdcontent

Articles Flash: Fail-Fast / Robustness, Rich/Anemic domain models

Some articles regarding design philosophies:
Domain models: rich or anemic? World is at fire, both have advantages, disadvantages.
Personally, I'm more of a data-driven anemic model.
Where business logic is governed by the business layer, and persistance by the persistance layer, the question is where the domain model resides. I like it more in the persistance layer. This does allow one to hopelessly mutilate the domain model in not allowed ways, but it also SOLID, since it only has one responsibility.
http://techblog.bozho.net/on-domain-driven-design-anemic-domain-models-code-generation-dependency-injection-and-more/
https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/
http://stackoverflow.com/questions/23314330/rich-vs-anemic-domain-model
And of course wikipedia:
https://en.wikipedia.org/wiki/Anemic_domain_model

For me, this is also because I'm not much of an OO-fan. Luckily, I'm not the only one:
http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html

now onto another biggie: fail-fast vs robustness.
Ideally, I'd like to to all my validation in the validation tier, i.e. in (or before) the front of the application. But it's reeeeeeeeeeeeeaaaally easy to just ad that if(something != null) in front of that callMyFunctionWhichUses(something)... Which is a bad thing, because now I've added complexity to my wonderful code, and a separate path. And from there, I might violate business concerns since I accidentily do not do critical stuff. And then I have to debug *why* I didn't do that critical stuff. And it's really hard. So ideally, I don't want that code... Unless it's going to a different system which should support it. If I have a call to a different system with optional fields, most of the time it's easier to just assume that my data is correct, and straight-through fill it to the external system. It'll have its own validation, and it'll tell me when I'm wrong, right?
Hmmm... maybe there's a fallacy there ;)
In any case, some articles:
http://www.yegor256.com/2015/08/25/fail-fast.html
We really should add wikipedia's here: https://en.wikipedia.org/wiki/Robustness_principle
And be aware that it has it's cost. It means deviating from specs for easy, forgiving applications. This, howver, in turn restrict us in further refactoring, since all of a sudden working code might break even if it still is up to spec, since bugs in neighboring code might accidentally use those undocumented features.

Labels

Labels:

Reacties

Een reactie posten

Populaire posts van deze blog

Spring's conditional annotation with properties

Spring has a nice @Conditional annotation, to have the option to have beans be available in the context depending a specific condition (Of course, this can also be realized by using @Configuration objects, but that's a different post). Ideally, we'd have the option to have a condition evaluate to true or false depending on a property. Sadly, Spring does not support that out of the box. Googling and looking around gives a partial solution, but the complete one here, so we won't forget: /** * Components annotated with ConditionalOnProperty will be registered in the spring context depending on the value of a * property defined in the propertiesBeanName properties Bean. */ @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Conditional(OnPropertyCondition.class) public @interface ConditionalOnProperty { /** * The name of the property. If not found, it will evaluate to false. */ String value(); /** * if the p...
Een reactie posten
Meer lezen

OSGI insights without sonar

So I was on a project without sonar. Oh my. Well, it was an OSGI project, so the problems couldn't be that bad, right? But how good were they (and what things were bad?) I found Stan4j , a code analysis tool for eclipse, which draws nice graphs and can handle osgi pretty well it seems. Now I can see that dependencies/bundle names aren't properly aligned (even though OSGI doesn't complain), etc.
Een reactie posten
Meer lezen

JPA and transactions

So I was working with JPA and transactions. Consider the following: In bean 1, with implicit TX 1, managed entities are loaded/created,and returned in bean 2, with implicit TX 2, entities are modified in bean 3, with NO TX, bean 1 is called, and the results are passed to bean 2. and bean 4 is similar to bean 3, but with it's own transaction, TX3 What happens when bean 3 finishes: are the entities updated? What happens when bean 4 finishes, are the entities updated? The answer to this is simple; entities are managed through a persistance context. That context is tied to the transaction. So in bean 2, there is a difference. When called from bean 3, it runs in a different transaction then bean 1, and thus a different persistance context, and thus the entities are not managed 'by this transaction'.When called from bean 4, it all runs in the same transaction, TX3, and the results are persisted.
Een reactie posten
Meer lezen