There are a lot of Cassandra API:s available and usually the programming language preference determines the choice of API.
However, if we take the programming language component out of the equation, what Cassandra API provides the highest level of abstraction?
Definition of "level of abstraction" in this context: An API providing a lot of extra goodies such as index handling, etc would be considered being at a higher abstraction layer than a bare bones "close to Thrift" API.
I guess you have found the ClientExamples page on the wiki.
You probably want to take a closer look at OCM which claims the following: "higher level client built on Hector"
Related
To ask this question in the shortest way possible: can they be different?
Background: Vlad Khononov in his excellent book 'Learning Domain-Driven Design (2021)' writes (p55):
The supplier's public interface is not intended to conform to its
ubiquitous language. Instead, it is intended to expose a protocol
convenient for the consumers, expressed in an integration-oriented
language.
In a sense, the open-host service pattern is a reversal of the anticorruption layer pattern: instead of the consumer, the supplier implements
the translation of its internal model.
Whereas, Olaf Zimmerman in a great article (2021) (https://eprints.cs.univie.ac.at/6948/1/europlop21-s16-camera-ready2.pdf) writes:
But in order to make the API understandable to domain experts, it is
essential that names and abstractions in the API follow the terms
defined in the ubiqitous language which is formally specified by the
domain model.
I think the anwer to question would be YES: it's possible to use different terms in published language and ubiquitous language for the same domain element. In the domain model you register the different terminology by applying 'aliases': an alias denotes the published language term used for an element in the domain model which is named according the ubiquitous language of the corresponsing bounded context.
What do you think?
The question is how much translation do Devs (internal and external) need to do between terms in the API vs. words in UL. It is almost always a trade-off, one that is shaped over time as the product and its API evolve.
All these patterns are acceptable and effective in their way:
A consumer-friendly API that at times deviates from UL
An API that reflects UL terms in APIs, ensuring internal and external stakeholders share the same view of the bounded context
A translation layer that maps the consumer-friendly external API to the internal UL terminology through aliases
Managing an external API means less wriggle room if you uncover terminology changes. Instead of trying to retain terms as-is, Approach 3 helps you improve the internal UL while still protecting the API sanctity.
You can start with Approach 2 by default and strive to retain it, but be open to being guided by external input and switch approaches.
Ubiquitous language
Internally restricted and applied only within a specific Bounded Context. Will lose meaning in other Bounded Contexts.
Commonly used by Domain Experts, Business Analysts, Engineers, etc. to communicate with each others under Bounded Context. Therefore, mainly expressed via human language writing/speaking (eg: English).
Published language
Publicly used to communicate (aka integrate) between different Bounded Contexts. Have agreed-meaning across Bounded Contexts.
Mainly used by engineers working in different Bounded Contexts to agree on integration approach (open-host, client-server, pub-sub, etc.). Therefore, mainly expressed via technical format (API, JSON, XML, Protocol Buffer, etc.)
I'm wondering if System Sequence Diagram (SSD) belongs to design part or analysis part?
A System Sequence Diagram (SSD) is be a special type of UML sequence diagram that intends to document for one specific use case the the sequence of exchanges between the system under consideration and the outside actors.
It is not a standard UML diagram, but build upon such diagrams. The book "System analysis and design in a changing world" seem to have popularized this approach, but I could find articles dating back to the early 2000' (like this or this).
The above mentioned book places the SSD in the analysis activities. The reason is that analysis is about understanding the requirements, which often start with use-case. The SSD is then a fine-tuning of this analysis.
However, one could argue that it's part of the design activities, since the use case are the requirements, but how these requirements are addressed through a sequence of exchanges is already the start of the design of a solution, exactly as when you start to sketch an UI: more than one SSD could satisfy the needs and you have the choice.
So the answer depends on the purpose for which you're using the model.
My own point of view is that you're already drafting a solution, so it should be design, unless you do some reverse engineering of an existing application, or your client has very detailed requirements
Elaborating a little on Christophe's answer:
I would add that analysis and design are two highly intertwined activities, so you would probably see these SSDs in both contexts and it would be perfectly fine and acceptable. Use Cases, those that involve a system, are necessarily a design artefact (they are a design of what the system does in relation to external actors) although you can of course see that same thing as a pure analysis output (telling you what the system is required to do). These things are very hard to separate. The point may seem philosophical (it is somewhat), but it is useful to think in these terms.
When you see people creating "Login" Use Cases you can bet they already stepped into pure design, in other words: functional decomposition. In analytical terms the state of a User being logged in is a constraint on a Use Case, not a Use Case itself. Having a Use Case called Login therefore represents only a design choice (incidentally, if you see this in contexts where there is a division of responsibilities between the people performing analysis and design, then you'd do well to consider it an analysis fail: the analyst is essentially designing the system and that's not their role). Analysts sometimes use Use Cases to model layers of requirements that relate only to business processes, usually referred to as "Business Use Cases", that don't involve any system per se. But the origins of Use Cases from 20-odd years ago was in the system space.
How do I determine what should I add to my use case diagrams? 1 for each button/form? Should things like sort and search be included? Or are they under "list items" for example? Though, a list of items seems understood?
The Use Case diagram is intended to help define the high-level business tasks that are important, not a list of functions of the system. For example, a system for use in customer service might involve a research task of looking up information to help someone on a support call.
Most of the literature describes Use Cases as a starting point for defining what the system needs to accomplish. The temptation has always been to be as complete as possible; adding ever more details to define the use case down to a functional (code-wise) level. While it is useful to have a comprehensive understanding of the requirements, the Use Case diagram is not intended to provide that level of documentation.
One thing that makes the issue worse is the syntax which I've never seen used in a working project. It isn't that the terms aren't useful, it's due to the lack of consensus over when to use either term for a given use case. The UML artifacts expect a process that is more focused on the business language instead of the implementation language - and by that I do not mean a computer language. The tendency by some has been to approach the diagrams with a legalistic bent and worry about things like when to use for related use cases or how to express error-handling as exceptions to a defined list of process tasks.
If you have ever tried to work through the Automated Teller Machine (ATM) example, you'll know what I mean. In the solar system of UML learning, the ATM example is a black hole that will suck you into the details. Avoid using it to understand UML or the Object Oriented Analysis and Design. It has many of the problems, typical of real-world domains, that distract from getting an overall understanding even though it would make for a good advanced study.
Yes, code will eventually be produced from the UML artifacts, but that does not mean they have to be debated like a treaty in the Senate.
The OMG UML spec says:
Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The subject is the system under consideration to which the use cases apply. The users and any other systems
that may interact with the subject are represented as actors. Actors always model entities that are outside the system.
The required behavior of the subject is specified by one or more use cases, which are defined according to the needs of actors. Strictly speaking, the term “use case” refers to a use case type. An instance of a use case refers to an occurrence of the
emergent behavior that conforms to the corresponding use case type. Such instances are often described by interaction specifications.
An actor specifies a role played by a user or any other system that interacts with the subject. (The term “role” is used
informally here and does not necessarily imply the technical definition of that term found elsewhere in this specification.)
Now most people would agree that business and user level interactions are the sweet spot, but there is no limitation. Think about the actors/roles being outside of the main system/systems you are focusing on. But in one view a system could be an actor, but in another the implementer of other use cases.
I'm building a small prototype of a Movies semantic search engine based on the data of LinkedIMDB
I've defined some Query Types as an example of use cases
search by entity name search by
entity type
search common features between two entities ...etc
So far I've developed a SPARQL engine that takes any type of those Queries and send the Query to the endpoint and preview the result.
The problem here is that I want to make a natural language or semi natural language interface for it in order for users to invoke those sentences using Natural language search Queries. But I don't know from where to start.
I've found some papers that are trying to extract triplets from the text but I don't feel that's the key to the solution.
Also I've found some LSA techniques to interpret Natural language search Queries but I feel it's not applicable to semantic search domain.
Any idea or resources to start reading from?
Is there a best practice than the natural language interface?
A lot of work has been done in the field of natural languge -> SQL conversion. Maybe you should take that as a starting point and see how you can modify the available examples for SPARQL. (Also, designing a controlled natural language could make your task easier.)
Another path to explore can be this article: Supporting Domain Experts to Construct Conceptual Ontologies: A Holistic Approach published at the Journal of Web Semantics, http://www.websemanticsjournal.org/index.php/ps/article/view/189 Even though it is about using natural language for ontology construction, the approach explained there (along with open source code) can turn into a fruitful exploration.
Have you seen FREya # https://github.com/nmvijay/freya it is an NLP to SPARQL convertor.
FREyA is an interactive Natural Language Interface for querying ontologies which combines usability enhancement methods such as feedback and clarification dialogs in order to:
1) improve recall by generating the dialog and enriching the domain lexicon from the user's vocabulary, whenever an "unknown" term appears in a question
2) improve precision by resolving ambiguities more effectively through the dialog. The suggestions shown to the user are found through ontology reasoning and are initially ranked using the combination of string similarity and synonym detection. The system then learns from the user's selections, and improves its performance over time.
I am fairly new to this discussion but I HAVE to ask this question even at the risk of sounding 'ignorant'. Why is it that we now stress so much on 'DDD'. The more I look into 'DDD' the more complex it seems to make my application. Whereas modeling my domain with the database helps keep my application consistent across layers. Then I can use DAL Helpers such as SubSonic or L2S to easily access that model. What is so bad about this? Even in enterprise applications?
Why do we strive to create a new way of modeling our domain when we have a tried and tested one?
I am willing to hear from the purists here.
You can't sell an old methodology, because too many projects failed and too many people know the old methodology anyway. There has to be a new one to market.
If you're doing fine with the old way then use what works. Do pay attention to new stuff, as some really nice ideas come along. But that doesn't mean everything old is bad and stupid. Usually you can incorporate new ideas into the old models to a large degree.
There does come a time to make a move. Like I wouldn't do OOP with structures and function pointers. ;-)
This is actually a really excellent question, and the short answer is "you can." We used to do it that way, and there was a whole area of enterprise (data) modeling. In fact, the common OOD notations evolved from ERD.
What we discovered, however, was that data-driven designs like that had some difficulties, the biggest of them being that the natural structure for a data base doesn't necessarily match well to the natural structure for code.
OOD, to a great extent, derives from the desire to make it easier to find a code structure that has a couple of desirable properties:
it should be easy to think out the design
it should be robust under changes.
The ease to think out design comes originally from Simula, which used what we now think of as "objects" for simulation specifically; it was convenient in simulation to have software entities that correspond to the things you're simulating. It was only later that Alan kay et al at Xerox saw that as a more general structuring method.
The part about robustness under changes had many parents, but one of the most important ones among them was Dave Parnas, you wrote several papers that identified a basic rule for modularization, which I call Parnas' Law: every module should keep a secret, and that secret is a requirements that is likely to change.
It turns out that by combining Parnas' Law with the Simula idea of a "object" as corresponding to something that can be identified with the real world, you tend to get system designs that are more robust under requirements changes than the old way we did things. (Not always, and sometime you have to be crafty, as with the Command pattern. Most objects are nouns, thing that have persistent existence. In the Command pattern, the ideal objects are verbs, things you do.)
However, it also turns out that that structure isn't necessarily a good way to represent the underlying data in a relational database, so we end up with the "object relational impedance mismatch" problem: how to represent the transformation from objectland to database-land.
Short answer: if all you need is a CRUD system that allows users to edit data, just build an Access front-end to your back-end database (or use a scaffolding framework like you mentioned) and call it a day. You should be able to lop off 70% of your budget vs. a domain-driven system.
Long answer: with a data-driven design, what does the implementation of the business model look like? Usually after a couple years of building on new features to your application, you'll find that it's all over the place: tables, views, stored procedures, various application services, code-behind files, presenters/ViewModels, etc. with duplication everywhere. When you're having a conversation with the domain expert about a new feature they are requesting, you are constantly trying to translate from the business language into the language around your implementation, and it just does not translate.
What typically ends up happening is that you are forced to communicate with the business in terms of the implementation of the system, and the implementation becomes the "ubiquitous language" that the business and developers are forced to use when communicating. This has a wide range of consequences. The domain experts in the business start believing that they are experts in the implementation domain, and they start demanding features in terms of implementation rather than the business need they are trying to solve.
Also, you'll find that most data-driven implementations do not follow the "conceptual contours" of the domain, and the components of the system aren't very flexible in how they can be combined together to solve the problem, because they don't map one-to-one with concepts in the business model. When code isn't cohesive, changes and new features may require modifications all over your implementation.
Domain Driven-Design provides tools for making your implementation so closely resemble the business model that it's easy for everyone to speak the language of the business. It allows you to write "executable specifications" that test your implementation, but can actually be understood by your domain experts.