CoR compared to Pipe and Filter

Java World implies the pipes-and-filters architectural style described by Parnas 

Software systems often employ the equivalent of pipes (e.g., email filters or a set of filters for a servlet). At the heart of pipes and filters lies a design pattern: Chain of Responsibility (CoR).

https://www.javaworld.com/article/2073684/java-web-development/follow-the-chain-of-responsibility.html

DCI Implementation in Java

In DCI the class definition "shouldn't contain a single method that is specific to an application’s use case;" i.e. "the domain object is not cluttered by peripheral stuff that it would not contain if not for some use case."
https://dzone.com/articles/dci-architecture-is-visionary

It's suggested that a language that supports DCI should be able to inject behaviors at run-time, which Java can't do as of yet (unless we count Java 8 interface default methods?).

Roles are applied in a run-time context where the roles connect the objects. The reason being is that if the objects (by their static definition i.e. their "class") contain static associations to each and every possible other object it could interact with at run-time, it would quickly proliferate the number of statically defined associations necessary -- hence the rule of thumb to forbid use-case specific behavior within a class.

As for Java, I believe a good trade-off is to either A) admit that the project's software does not pertain to the "domain" at all but that all the objects defined are understood to be within the scope of the project's set of use-cases in that way it's ok to add use-case-specific behavior in the class definition; or B) keep the object's dumb as prescribed by DCI and then let the role's be statically defined and allow the number of the role "classes" to proliferate as needed to accommodate all the use-cases (algorithms plus associations to objects defined in the roles.) (In the latter case, a role is analogous to join table in SQL.)

Regarding option B: obviously DCI assumes domain objects pertain to the larger "domain" of the business and should stay more-or-less static, each maintaining its separate set of invariants. Therefore it might make sense to have use-case specific packages where all the use-case or project specific behaviors and associations among the domain objects are defined in a set of roles residing in their own project/use-case package, which serves as the context in DCI. You could even have a separate Spring XML config file containing all the associations between the use-case-specific classes and the domain objects -- injections go from the latter to the former but not the reverse unless via non-use-case-specific interfaces -- for this reason you would not be able to use @Autowired...@Qualifier because using annotations this way couples the class file definition itself to the use-case-specific algorithm and runs the risk of that proliferation of use-case-specific code in the domain class definition.

I actually lean toward A. My rationale is that the notion of a "domain" sounds nice in theory but in practice it's hard to scope and define because "domains" often overlap -- even if you consider the domain to be the entire enterprise, it may overlap with other enterprises at any given juncture due to mergers or joint ventures. My preference is to actually create project or epic specific models that reside in say a "model" package. These models can be transcripted via tools like ModelMapper or Dozer. Once the project has access to its own possibly trimmed-down model it might make sense to add use-case specific behavior to the model classes since the number of use-cases within a project/epic are likely to be limited in number, so the risk of object-to-object static coupling is minimized. That said, even here I prefer to use "role objects" that contain the algorithms and associations, so you still get DCI in a sense but without worrying about maintaining that nebulous domain concept.

Algorithms and OOP

In addition to DCI, "generic programming" as well as the move to functional programming appears to add nuance to the OOP notion of joining behavior with data, at the least at the static class definition level. In other words, the notion of OOP I think is becoming more of a runtime notion rather than static notion where the object's definition is enhanced at runtime with injected behaviors, rather than having those behaviors baked into the object's class definition.

The Iterator abstraction is fundamental to an emerging technology called "generic programming". This strategy seeks to explicitly separate the notion of "algorithm" from that of "data structure". The motivation is to: promote component-based development, boost productivity, and reduce configuration management.

https://sourcemaking.com/design_patterns/iterator

Business Logic in OOP

It appears logic should not be mistaken with behavior when it comes to OOP, which embraces the coupling of state and behavior (that modifies that state). Logic belongs elsewhere, e.g. in a rules engine.

One of the "Advantages of [a] Rule Engine" is "Logic and Data Separation (breaking OO coupling of data and logic)" - http://training-course-material.com/training/JBPM_and_Drools_Introduction

Which tables are affected is business logic as well. The database should not have any knowledge of which tables constitute a customer on the business level. These are better served in the business layer.

https://www.codeproject.com/Articles/10746/Dude-where-s-my-business-logic

Static State Shared from Libs Shared Among Webapps

One of the disadvantages of placing application libraries in the Tomcat lib folder is thread safety issues.

... if any of the classes has static state, you will find that the state is now shared across all webapps. This can cause the objects / types from one webapp to be seen by another, which can cause problems.

Stephen C http://stackoverflow.com/questions/12162654/how-to-make-war-file-take-up-less-memory

Advantage of Compiled vs Interpreted Languages

Same reason you'd choose GWT vs JavaScript:

One of the primary ways GWT speeds AJAX development is by allowing you to write your applications in the Java language. Because of this, you can take advantage of static type checking and time-tested patterns of object-oriented programming. These, when combined with modern IDE features like code completion and automated refactoring, make it easier than ever to write robust AJAX applications with well-organized code bases.

http://www.gwtproject.org/doc/latest/tutorial/codeclient.html

so:
1) static type checking
2) code completion
3) automated refactoring

How Agents Work

Wondering about exactly what agents are and what they are supposed to do. Finally found a simple example scenario which I believe is a compelling reason to use agents for when appropriate (in this case negotation):

Agents cooperate on a number of levels. First, they share their perception.
Next, we enabled our agents to share their agent state (e.g. that the
agent carries no gold items) and intentions (such as “I plan to pick gold at
X,Y”) as they may choose to go to the same unknown field or to pick the
same gold item. Now every agent can appraise from what it knows if it will
be better to leave the team member alone or to take the intention as its
own when its more promising.
Our approach to communication and cooperation is fully decentralised.
Each agent has the capability for finding the other agent on the network.
It then directly tells every agent about its perception, agent state and intentions.
There is neither a message broker nor a central instance which
coordinates the contest agents. Every agent builds its own world model from
what it is told by the server and the other agents. Every agent also plans for itself, taking the states and intentions of its teammates into account.

opus4.kobv.de/opus4-tuberlin/files/3610/hessler_axel.pdf

OWL vs Java

Also be careful when declaring properties: properties in OWL can inherit other
properties and can be attached to more then one class. Not so in Java.

opus4.kobv.de/opus4-tuberlin/files/3610/hessler_axel.pdf

Modified Command Pattern

There's some support for a sort of split Command Pattern where the data lives in one object called the "Command" while the behavior resides explicitly in another object e.g. "handler" or implicitly as in the case of Spring MVC (see example code).

As mentioned it appears in Spring MVC and more recently adopted by CQRS developers.

see http://stackoverflow.com/questions/6617976/dependency-injection-when-using-the-command-pattern and https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91

It has benefits for testing because the runtime data is separated from the compile time behavior. This separation is discussed  in the context of dependency injection by Misko Hevery.

I wonder though what OO proponents like Martin Fowler would say to this; i.e. would they deem the artifacts, the commands, to make up an anemic domain model?

On the other hand, according to some the trend seems to be toward separating behavior from objects in certain respects. E.g. I recall Coplien (of DCI) saying "good objects are dumb" implying albeit that the behavior can be injected at runtime. So maybe that's not the best example. But here's a quote from 'User' on Stackoverflow for what it's worth. It's on the example of where should 'validate()' go:

I think in the past CreditCard.Validate() would have been considered good object oriented design but the trend seems to be away from that towards many separate classes.

http://stackoverflow.com/questions/3117800/dependency-injection-when-the-class-created-also-needs-runtime-values

However, Ayende Rahien asserts the opposite is (or should be) taking place (i.e. to move toward putting data and behavior back together?): http://ayende.com/blog/4503/component-oriented-design-and-why-it-be-retired

Notes
The author of this Command/Handler pattern also demonstrated the Query/Handler analog which is extremely telling and revolutionary with regard to deconstructing the Repository pattern as it's commonly implemented: https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=92

Class Factories and Factory Scopes

Misko Hevery seems to favor factories that perform the manufactoring process for all objects within an object lifetime. See http://misko.hevery.com/2009/03/30/collaborator-vs-the-factory/
This leads to aggregate factories for different scopes such as Application, servlet, Request, etc. I consider these to be equivalent to the IoC container as in Spring's ApplicationContext which is a  factory i.e. a BeanFactory.

But what about "small lifetime" objects which are the factories we usually think of as in the Factory Method pattern which create objects on the fly? This is broached to Misko by Giorgio Sironi at http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/ regarding the creation of a TagFactory as "an example of creation of non-newables (Song example) in the application logic, that is simply delegation to the TagFactory" - alluding to http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/.

Surprising Misko didn't have much to say on it other than "I think you are on the right track."

Mocks Shouldn't Return Mocks

It appears to be a code smell when a mock returns a mock. See hints of why from this thread: http://programmers.stackexchange.com/questions/232442/unit-testing-factories-and-the-law-of-demeter which point to here which shows how application of LoD quickly fixes the problem.

Misko Hevery says the mocked item, e.g. the factory, should actually be returning a "newable" -- the exception being when returning third party objects such as java.io.File. See response to Tom at http://misko.hevery.com/your-suggestions/

Middle Ground between 'Newable' and 'Injectable'?

As noted previously, Misko Hevery asserts that every objects should be either an "injectable" or a "newable."

The question is: why does then Spring support prototype scoped objects which can be injected with well injectables? The condensed and recently supported alternative (through this initiative) to creating a prototype scope object -- which requires access to the ApplicationContext through ApplicationContextAware or BeanFactoryaware (not good* because it becomes a Service Locator "DI Catch 22") -- i.e. the @Lookup or lookup-method with parameters supported is really just syntactic sugar for a prototype scope object, IMO.

On the other hand, the fact that Spring does the wiring under the covers may make @Lookup-with-parameters okay. However, if one tried to do the same in code it would probably violate Misko's rule stating you should not inject an injectable into a newable, where the newable is the prototyped scoped object.


*Note: it may be more nuanced than black and white whether usage of an injected ApplicationContext is or is not good IoC. e.g. see comments by Alex Worden regarding enabling a sort of polymorphism where you "dynamically create new bean instances based on a bean name that is unknown at compile time but matches one of the implementations defined in my spring.xml file" - http://stackoverflow.com/questions/812415/why-is-springs-applicationcontext-getbean-considered-bad this might be a valid use of 'ContextAware. Commenters note that this is not really IoC but rather ordinary factory or Service Locator but pap notes that "Spring is about more than just IoC."

Similar question raised here.

Found this problem is similar to the question of how to do DI and the Command Pattern at the same time. Turns out they may be incompatible. see and see

DI - When to 'new'

Misko advises to keep "newables" separate from "injectables" - so newing things up are okay if they are value objects. http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

I go to that article via a comment in http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/  where he's emphatic about doing the DI. The "newable" exception is very important to consider. Specifically, a newable is an object a DI container would have NO WAY of know how to instantiate -- like a User() or PhoneNumber.

Continued...

Repository vs. Service

One issue causing confusion about whether to choose a repository or a service is where to put business logic methods like getEntityItemBySomeAttribute(attribute).

The use of Specifications in a standard query method seems to solve this problem.

Where you would want to choose the Service instead is when the logic of the query spans multiple repositories or a combination of repositories and external services -- this is DDD guidance.

Be mindful of the difference between APIs and SPIs. APIs should be final concrete classes and SPIs should be Interfaces. The clients of APIs are callers while the clients of SPIs are implementers.

I've noticed that repositories are typically SPIs while services are typically APIs.

Refs:
http://wiki.apidesign.org/index.php?title=APIvsSPI&useskin=monobook
https://docs.oracle.com/javase/tutorial/ext/basics/spi.html
http://stackoverflow.com/questions/12317126/onion-architecture-repository-vs-service
http://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/ -- notes that DAOs are no longer favored because they are too general and loosely typed.

-------
2015-09-03
Current common practice appears to have a topology like Service<T> --injected with--> Repository<T> --injected with--> JDBCTemplate or DataSource. see http://stackoverflow.com/a/24083073/2066936

CQRS and Architecture

lecture from several years ago. Items of interest are  

• an architecture graphic from 48:57 picturing both validation and business rules as components as opposed to layers
• the idea that a database ("persistent viewmodel") with viewmodel tables should replace the in-memory caches
• capturing the user's intent is not necessarily the same as editing a row in the database: "The fact that they are two columns on the same entity does not mean anything!"
• Example of user's intent is "reserve a block of seats on airplane for family/friends" but UI given is seats with checkboxes and a refresh button (to see what's changed to allow what they want)
• What are domain models for?
• "Domain models aren't for validation." Validation is there in its own component"
• see graphic from 48:57 and 1:29:38 where domain model is the "Rules" component
• validation component is actually the same one on the client-side and server-side (see graphic)
• Domain models aren't for queries.
• Domain models are for business rules: e.g. figuring out how much interest to charge once the user has violated terms of agreement and over-withdrawn their account despite the best-efforts of the client-side validation logic.
• Domain models are for doing what business people spend time on -- thinking of "adding weird ways to add functionality to the system to delight their customers" e.g. is it their birthday, should I send them a birthday present, is he a preferred customer, etc.
• "Client-side controllers [that are using the CQRS queries] are supposed to do [business] logic. It's not that big a deal"
• Quote on commands, that they must go through asynchronous messaging pipeline: "You need to design your commands such that you can say 'Thank you. Your email confirmation will arrive shortly."
• On Relationships
• "Once you've taken out all the relationships from your domain models they've actually become smaller and tighter -- focused really just on processing commands"
• And DTOs, ORM, etc. is removed from the query procesing and replaced with the one-table per view ViewModel (note points on search recommendations and removing ability to do complex queries from the user)

Quotes:
"Writing a custom form to accept: how many seats do you want? What kind of seats do you want? Trivial forms to write. Writing these query screens, now that you don't have to go through DTOs and domain models and object-relational mappers, and god-knows what else -- these are a lot of easier to write too! Once you've taken all these relationships from your domain models, they've also become quite a bit smaller and tighter focused really just on processing commands.

"Yes you do need to understand what your users are using the system for. Otherwise just give them access to your database and be done with it. "

"You can't shoehorn a CQRS architecture underneath an editable datagrid. Do not try. User interface design is as much a part of architecture as anything else that you do."

https://skillsmatter.com/skillscasts/1250-udi-dahan-command-query-responsibility-segregation#video

Domain Service vs Application Service

• If you follow Domain Driven principle, Order is a domain object but Email Sender maybe is a service ( different from Domain Service ) so you can’t use it in your model.

http://www.javacodegeeks.com/2013/08/how-to-use-events-in-spring-3-x.html

Other times I think of services as little classes that don't represent a particular person, place, or thing in my application, but that tend to embody processes. Domain services usually fall in this latter category. They tend to be named after verbs or business activities that domain experts introduce into the Ubiquitous Language

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx#id0090088 - goes on to describe in contrast how application services perform mapping between layers or other modules

From Singleton to AOP (And Everything in Between)

This article on game development touches on the nuances faced and the angst developers face when dealing with complex systems and still adhering to best practices ala IoC. The highest voted answer seems to favor neither the service locator pattern nor the singleton, but seems to lean toward dependency injection ("passing around the instances"). Nevertheless the OP appears to settle on Service Locator.
http://gamedev.stackexchange.com/questions/84197/how-can-i-avoid-having-many-singletons-in-my-game-architecture

An alternative to all three could be AOP as shown in this old article: http://blogs.msdn.com/b/simonince/archive/2008/06/30/dependency-injection-is-dead.aspx

But if you think that DI is hard, DI via AOP is certainly an order of magnitude harder -- which is probably why it's not spoken of much.

Private Inner / Local Classes - Advantages / Disadvantages

Good debate found here: http://stackoverflow.com/questions/3353318/how-do-i-test-local-inner-class-methods-in-java

The consensus (and accepted answer) is that in general if it's important enough for a local / private inner class to be tested, it should refactored out, e.g. to a separate package.

On the other hand, "bob" makes a good point about keeping the class internal as an implementation detail for the sake of cohesion.

Kai Sternad provides an answer that probably could have been accepted.

Transactions and ACID Principle

http://blogs.curtin.edu.au/webdev/2010/05/09/nested-cf-transaction-blocks/ - article gives good use case for nested transactions: insert user, then add-or-update content items which are associated to the new user.

Django and MTV

MTV for Model Template View, to replace respectively Model View Controller
http://www.djangobook.com/en/2.0/chapter05.html