160:"Of all the SOLID principles, the Single Responsibility Principle (SRP) might be the least well understood. That’s likely because it has a particularly inappropriate name. It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing. Make no mistake, there is a principle like that. A function should do one, and only one, thing. We use that principle when we are refactoring large functions into smaller functions; we use it at the lowest levels. But it is not one of the SOLID principles—it is not the SRP. (...) the final version of the SRP is: A module should be responsible to one, and only one, actor."
92:
be as simple as displaying information in the database. In others it may involve many steps of validations and calculations. A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper. Each transaction will have its own
Transaction Script, although common subtasks can be broken into subprocedures.
214:), which by itself does not implement any of the business concerns, in this case, that a height or a width cannot be zero or negative, or that somewhere else there is a requirement for the area of the rectangle. This means that those functionalities are implemented somewhere else, no longer on the "business" side of the program, but somewhere else hidden within its architecture.
91:
Most business applications can be thought of as a series of transactions. A transaction may view some information as organized in a particular way, another will make changes to it. Each interaction between a client system and a server system contains a certain amount of logic. In some cases this can
55:
The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented designing; which is to combine data and process together. The anemic domain model is just a procedural style design, exactly the kind of thing that object bigots like me ... have been fighting
287:
A non-anemic rewrite of the above class could look like the following. The business concerns are now handled in the domain object, while the architecture can be more domain-agnostic. This allows the program to assume certain attributes are true about objects without implementing validity checks
650:, an anemic domain model is the typical result of not applying the information expert principle, i.e. you can avoid an anemic domain model by trying to assign responsibilities to the same classes that contain the data
96:
In his book "Patterns of
Enterprise Application Architecture", Fowler noted that the transaction script pattern may be proper for many simple business applications, and obviates a complex OO-database mapping layer.
35:
like validations, calculations, rules, and so forth. The business logic is thus baked into the architecture of the program itself, making refactoring and maintenance more difficult and time-consuming.
100:
An anemic domain model might occur in systems that are influenced from
Service-Oriented Architectures, where behaviour does not or tends to not travel, such as messaging/pipeline architectures, or
84:
applications following the Three-Layered
Services Application architecture where such objects fall into the category of "Business Entities" (although Business Entities can also contain behavior).
64:
In an anemic domain design, business logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes
195:'s objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
797:
116:
There is some criticism as to whether this software design pattern should be considered an anti-pattern, since many see also benefits in it, for example:
60:. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.
132:
More compatibility with mapping and injection frameworks expecting dumb properties rather than a specific constructor or property population order.
773:
685:
741:
108:
APIs. Architectures like COM+ and
Remoting allow behaviour, but increasingly the web has favoured disconnected and stateless architectures.
833:
727:
828:
818:
44:
177:
145:
858:
647:
211:
843:
863:
637:
642:
689:
791:
710:
181:
169:
Certain liabilities the programmer must consider are introduced by using an anemic domain model:
779:
769:
198:
Needs a service layer when sharing domain logic across differing consumers of an object model.
153:
814:
671:
838:
823:
81:
32:
28:
742:"The Anaemic Domain Model is no Anti-Pattern, it's a SOLID design – SAPM: Course Blog"
728:"The Anaemic Domain Model is no Anti-Pattern, it's a SOLID design – SAPM: Course Blog"
136:
A common criticism is the idea that anemic domain model makes it easier to follow the
852:
69:
192:
188:
48:
24:
210:
An anemic domain model would have one write code like the following (written in
77:
783:
765:
Clean architecture : a craftsman's guide to software structure and design
187:
Needs a separate business layer to contain the logic otherwise located in a
72:
applications, possibly encouraged by technologies such as early versions of
57:
763:
148:, which suggests that a class should do one thing, and do it well (...)".
686:"Application Architecture for .NET: Designing Applications and Services"
829:
Application
Architecture for .NET: Designing Applications and Services
137:
105:
101:
73:
173:
Logic cannot be implemented in a truly object-oriented way.
126:
Results in stateless logic, which facilitates scaling out.
834:
Article on why anemic model may be considered good design
129:
Avoids the need for a complex OO-Database mapping layer.
87:
Fowler describes the transaction script pattern thus:
156:, this is a misunderstanding of that principle:
89:
53:
8:
796:: CS1 maint: location missing publisher (
201:Makes a model less expressive. .
43:This anti-pattern was first described by
666:
664:
120:Clear separation between logic and data.
660:
68:. This pattern is a common approach in
789:
722:
720:
7:
288:elsewhere within the architecture.
123:Works well for simple applications.
824:Three-Layered Services Application
14:
844:How to Avoid Anemic Domain Model
47:, who considers the practice an
146:Single Responsibility Principle
711:"P of EAA: Transaction Script"
23:is described as a programming
1:
839:Writing Clean Code in ASP.NET
557:ArgumentOutOfRangeException
470:ArgumentOutOfRangeException
880:
762:Martin, Robert C. (2018).
672:"Bliki: AnemicDomainModel"
648:GRASP information expert
290:
216:
56:since our early days in
16:Programming anti-pattern
144:"The ‘S’ refers to the
162:
150:
94:
62:
859:Software architecture
638:Plain old Java object
191:. It also means that
158:
142:
31:contain little or no
643:Domain-driven design
815:Anemic Domain Model
66:transaction scripts
21:anemic domain model
730:. 4 February 2014.
182:information hiding
152:But, according to
775:978-0-13-449432-6
744:. 4 February 2014
176:Violation of the
871:
802:
801:
795:
787:
759:
753:
752:
750:
749:
738:
732:
731:
724:
715:
714:
707:
701:
700:
698:
697:
688:. Archived from
682:
676:
675:
668:
627:
624:
621:
618:
615:
612:
609:
606:
603:
600:
597:
594:
591:
588:
585:
582:
579:
576:
573:
570:
567:
564:
561:
558:
555:
552:
549:
546:
543:
540:
537:
534:
531:
528:
525:
522:
519:
516:
513:
510:
507:
504:
501:
498:
495:
492:
489:
486:
483:
480:
477:
474:
471:
468:
465:
462:
459:
456:
453:
450:
447:
444:
441:
438:
435:
432:
429:
426:
423:
420:
417:
414:
411:
408:
405:
402:
399:
396:
393:
390:
387:
384:
381:
378:
375:
372:
369:
366:
363:
360:
357:
354:
351:
348:
345:
342:
339:
336:
333:
330:
327:
324:
321:
318:
315:
312:
309:
306:
303:
300:
297:
294:
283:
280:
277:
274:
271:
268:
265:
262:
259:
256:
253:
250:
247:
244:
241:
238:
235:
232:
229:
226:
223:
220:
154:Robert C. Martin
80:, as well as in
879:
878:
874:
873:
872:
870:
869:
868:
849:
848:
811:
806:
805:
788:
776:
761:
760:
756:
747:
745:
740:
739:
735:
726:
725:
718:
709:
708:
704:
695:
693:
684:
683:
679:
670:
669:
662:
657:
634:
629:
628:
625:
622:
619:
616:
613:
610:
607:
604:
601:
598:
595:
592:
589:
586:
583:
580:
577:
574:
571:
568:
565:
562:
559:
556:
553:
550:
547:
544:
541:
538:
535:
532:
529:
526:
523:
520:
517:
514:
511:
508:
505:
502:
499:
496:
493:
490:
487:
484:
481:
478:
475:
472:
469:
466:
463:
460:
457:
454:
451:
448:
445:
442:
439:
436:
433:
430:
427:
424:
421:
418:
415:
412:
409:
406:
403:
400:
397:
394:
391:
388:
385:
382:
379:
376:
373:
370:
367:
364:
361:
358:
355:
352:
349:
346:
343:
340:
337:
334:
331:
328:
325:
322:
319:
316:
313:
310:
307:
304:
301:
298:
295:
292:
285:
284:
281:
278:
275:
272:
269:
266:
263:
260:
257:
254:
251:
248:
245:
242:
239:
236:
233:
230:
227:
224:
221:
218:
208:
167:
114:
41:
17:
12:
11:
5:
877:
875:
867:
866:
861:
851:
850:
847:
846:
841:
836:
831:
826:
821:
810:
809:External links
807:
804:
803:
774:
754:
733:
716:
702:
677:
659:
658:
656:
653:
652:
651:
645:
640:
633:
630:
291:
217:
207:
204:
203:
202:
199:
196:
185:
174:
166:
163:
134:
133:
130:
127:
124:
121:
113:
110:
40:
37:
33:business logic
29:domain objects
15:
13:
10:
9:
6:
4:
3:
2:
876:
865:
864:Anti-patterns
862:
860:
857:
856:
854:
845:
842:
840:
837:
835:
832:
830:
827:
825:
822:
820:
819:Martin Fowler
816:
813:
812:
808:
799:
793:
785:
781:
777:
771:
767:
766:
758:
755:
743:
737:
734:
729:
723:
721:
717:
712:
706:
703:
692:on 2013-01-10
691:
687:
681:
678:
673:
667:
665:
661:
654:
649:
646:
644:
641:
639:
636:
635:
631:
599:CalculateArea
289:
215:
213:
205:
200:
197:
194:
190:
186:
183:
179:
178:encapsulation
175:
172:
171:
170:
164:
161:
157:
155:
149:
147:
141:
139:
131:
128:
125:
122:
119:
118:
117:
111:
109:
107:
103:
98:
93:
88:
85:
83:
79:
75:
71:
67:
61:
59:
52:
50:
46:
45:Martin Fowler
38:
36:
34:
30:
26:
22:
764:
757:
746:. Retrieved
736:
705:
694:. Retrieved
690:the original
680:
286:
209:
193:domain model
189:domain model
168:
159:
151:
143:
140:principles:
135:
115:
99:
95:
90:
86:
78:Entity Beans
65:
63:
54:
49:anti-pattern
42:
25:anti-pattern
20:
18:
184:principles.
165:Liabilities
51:. He says:
853:Categories
784:1003645626
768:. Boston.
748:2022-09-14
696:2013-02-13
655:References
27:where the
792:cite book
425:SetHeight
392:SetHeight
365:Rectangle
296:Rectangle
222:Rectangle
112:Criticism
58:Smalltalk
632:See also
512:SetWidth
404:SetWidth
39:Overview
350:private
320:private
206:Example
782:
772:
611:Height
608:return
593:public
563:nameof
506:public
497:height
491:Height
482:height
476:nameof
449:height
434:height
419:public
398:height
374:height
362:public
332:public
308:Height
302:public
255:public
234:Height
228:public
617:Width
584:width
578:Width
569:width
551:throw
539:<=
536:width
521:width
464:throw
452:<=
410:width
383:width
338:Width
293:class
261:Width
219:class
138:SOLID
798:link
780:OCLC
770:ISBN
509:void
422:void
180:and
106:REST
102:SOAP
82:.NET
70:Java
19:The
817:by
596:int
572:));
554:new
518:int
485:));
467:new
431:int
380:int
371:int
353:set
344:get
335:int
323:set
314:get
305:int
273:set
267:get
258:int
246:set
240:get
231:int
76:'s
74:EJB
855::
794:}}
790:{{
778:.
719:^
663:^
602:()
530:if
443:if
413:);
401:);
212:C#
800:)
786:.
751:.
713:.
699:.
674:.
626:}
623:}
620:;
614:*
605:{
590:}
587:;
581:=
575:}
566:(
560:(
548:{
545:)
542:0
533:(
527:{
524:)
515:(
503:}
500:;
494:=
488:}
479:(
473:(
461:{
458:)
455:0
446:(
440:{
437:)
428:(
416:}
407:(
395:(
389:{
386:)
377:,
368:(
359:}
356:;
347:;
341:{
329:}
326:;
317:;
311:{
299:{
282:}
279:}
276:;
270:;
264:{
252:}
249:;
243:;
237:{
225:{
104:/
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.