Related
I have flicked through few popular Event Sourcing frameworks written in a variety of different common languages. I have got the impression all of them affect the domain models to a really high degree. As far as I understand ES is just an infrastructure concern - a way of persisting aggregate state. Of course, it facilitates message driven inter-context integration but in core domain's point of view is negligible. I consider commands and events to be part of the domain itself so it looks perfectly fine that aggregate creates events (but not publishes them) or handles commands.
The problem is that all of DDD building blocks tend to be polluted by ES framework. Events must inherit from some base class. Aggregates at least are supposed to implement foreign interfaces. I wonder if domain models should be even aware of using ES approach within an application. In my opinion, even necessity of providing apply() methods indicates that other layer shapes our domain.
How you approach this issue in your projects?
My answer applies only when CQRS is involved (write and read models are split and they communicate using domain events).
As far as I understand ES is just an infrastructure concern - a way of persisting aggregate state
Event sourcing is indeed an infrastructure concern, a kind of repository but event-based Aggregates are not. I consider them to be an architectural style, different from the classical style.
So, the fact that an Aggregate, in reaction to an command, generates zero or more domain events that are applied onto itself in order to build its internal (private) state used to decide what events to generate in the future is just a different mode of thinking and designing an Aggregate. This is a perfect valid style, along with classical style (the one not using events but only objects) or functional programming style.
Event sourcing just means that every time a command reaches an Aggregate, its entire internal state is rebuild instead of being loaded from a flat persistence. Of course there are other huge advantages (!) but they do not affect the design of an Aggregate.
... but not publishes them ...
I like the frameworks that permit us to just return (or better yield - Aggregate's command methods are just generators!) the events.
Events must inherit from some base class
It's sad that some frameworks require that but this is not necessarily. In general, a framework needs one mean of detecting an event class. However, they can be implemented to detect an event by other means instead of using marker interfaces. For example, the client (as in YOU) could provide a filter method that rejects non-event classes.
However, there is one thing that I couldn't avoid in my framework (yes, I know, I'm guilty, I have one): the Command interface with only one method: getAggregateId.
Aggregates at least are supposed to implement foreign interfaces.
Again, like with events, this is not a necessity. A framework could be given a custom client event-applier-on-aggregates function or a convention can be used (i.e. all event-applier methods have the form applyEventClassNameOrType.
I wonder if domain models should be even aware of using ES approach within an application
Of ES not, but event-based YES, so the apply method must still exists.
As far as I understand ES is just an infrastructure concern - a way of persisting aggregate state.
No, events are really core to the domain model.
Technically, you could store diffs in a domain agnostic way. For example, you could look at an aggregate and say "here is the representation before the change, here is the representation after, we'll compute the difference and store that.
The difference between patches and events is the fact that you switch from a domain agnostic spelling to a domain specific spelling. Doing that is normally going to require being intimate with the domain model itself.
The problem is that all of DDD building blocks tend to be polluted by ES framework.
Yup, there's a lot of crap framework in the examples you find in the wild. Sturgeon's Law at work.
Thinking about the domain model from a functional perspective can help a lot. At it's core, the most general form of the model is a function that accepts current state as an input, and returns a list of events as the output.
List<Event> change(State current)
From there, if you want to save current state, you just wrap this function in something that knows how to do the fold
State current = ...
List<Event> events = change(current)
State updated = State.fold(current, events)
Similarly, you can get current state by folding over the previous history
List<Event> savedHistory = ...
State current = State.reduce(savedHistory)
List<Event> events = change(current)
State updated = State.fold(current, events)
Another way of saying the same thing; the "events" are already there in your (not event sourced) domain model -- they are just implicit. If there is business value in tracking those events, then you should replace the implementation of your domain model with one that makes those events explicit. Then you can decide which persisted representation to use independent of the domain model.
Core of my problem is that domain Event inherits from framework Event and aggregate implements some foreign interface (from framework). How to avoid this?
There are a couple of possibilities.
1) Roll your own: take a close look at the framework -- what is it really buying you? If your answer is "not much", then maybe you can do without it.
From what I've seen, the "win" of these frameworks tends to be in taking a heterogeneous collection of events and managing the routing for you. That's not nothing -- but it's a bit magic, and you might be happier having that code explicit, rather than relying on implicit framework magic
2) Suck it up: if the framework is unobtrusive, then it may be more practical to accept the tradeoffs that it imposes and live with them. To some degree, event frameworks are like object relational mappers or databases; sure, in theory you should be able to change them out freely. In practice? how often do you derive benefit from the investment in that flexibility
3) Interfaces: if you squint a little bit, you can see that your domain behaviors don't usually depend on in memory representations, but instead on the algebra of the domain itself.
For example, in the domain model, we deposit Money into an Account updating its Balance. We don't typically care whether those are integers, or longs, or floats, or JSON documents. We can satisfy the model with any implementation that satisfies the constraints of the algebra.
So you can use the framework to provide the implementation (which also happens to have all the hooks the framework needs); the behavior just interacts with the interface it defined itself.
In a strongly typed implementation, this can get really twisty. In Java, for instance, if you want the strong type checks you need to be comfortable with the magic of generics and type erasure.
The real answer to this is that DDD is overrated. It is not true that you have to have one model to rule them all. You may have different views on the state of your world, depending on your current needs. One part of the application has one view, another part - completely different view.
To put it another way, your model is not "what is", but "what happened so far". The actual data model of your application is the event stream itself. Everything else you derive from there.
I am new in papyrus modelling. I asked the same question in Papyrus forum, but I didn't get any reply. I believe, somebody could help me in this regard. Anyway, I am wondering how to do aspect-oriented modelling in papyrus state machine. I have some state machine. where each state has it's own state invariant. Apart from this, there is a number of constraints that act as state invariant in multiple states. So, adding all of those constraints as state invariant in each of those states would make the state machine more complex and messy. Probably, aspect-oriented modelling is a better option in this scenario. So, a single constraint can be added to the state invariant of states of the same aspect. i.e., the complete state invariant of a state would be its own state invariant and the constraint from the aspect.
Is this possible in papyrus? Any idea how to do this? Any suggestion?
DDD is Domain-Driven Design , it is a methodology that include ubiquitous language, root entity , value object and aggregations..
DCI: Data, Context, Interactions is a programming paradigm invented by Trygve Reenskaug.
how can I combine with them in a new system?
This is a subject of on going discussion, and something you'll probably find better answers to at the object-composition Google group where it has been discussed earlier. Also there is an effort to port the canonical DDD sample to DCI at the DCI github page.
Long story overly short though: DCI fits within a Bounded Context, where you'd then have a DCI context per use case.
If you read through this https://msdn.microsoft.com/en-us/library/jj554200.aspx I believe the DCI notion of a "context" would be synonymous with a "process manager". Instead of the process manager calling methods on the aggregates, it would apply roles to the aggregates and coordinate using those. A "bounded context" could have several "process managers" aka "contexts". What do you think?
I want to model an activity, where there can be two several initiating events. These events has two several responsible actors. Is it allowed that a UML activity-diagram could have two initiating events and only one end? Could the action-flow be joined?
I want to know if I defy against the UML-modeling principles, if I do this.
Would be nice, if there are some hints for me.
Greetings,
Martin
The UML 2.3 superstructure specification (p389) says:
An activity may have more than one initial node.
and
If an activity has more than one initial node, then invoking the activity starts multiple flows, one at each initial node.
So according to the UML spec you're not violating the rules.
That said, #Dave is on the money - the most important thing is your model makes sense to you and those who will consume it. The UML specification is so riddled with inconsistency and ambiguity that it's questionable what 'being compliant' even means.
So long as you and all users of the model have a common understanding of what it's representing then don't get hung up on the UML's pseudo-semantics.
(Of course, this assumes you're using the model as a picture for communication, not as a formal specification that will be interpreted/compiled to code. If so, you'll need to formalise your own semantics for what it means).
By the way - with reference to data modelling I'm referring to logical or conceptual data models - not physical ones.
The question came up during a discussion at work; naturally I leapt to Wikipedia to get some basic definitions in place - hoping that they might clarify the difference - but they didn't...
A conceptual schema or conceptual data model is a map of concepts and their
relationships.
Logical Data Modles seem very similar (from this definition):
A logical data model (LDM) in systems
engineering is a representation of an
organization's data, organized in
terms entities and relationships and
is independent of any particular data
management technology.
Where-as...
A domain model, or Domain Object Model
(DOM) in problem solving and software
engineering can be thought of as a
conceptual model of a system which
describes the various entities
involved in that system and their
relationships.
The differences between domain model vs conceptual data model seems particularly murky.
One of the things which adds to this confusion is that (from what I've seen) a domain model is usually modelled using a UML class diagram - the class entity in a UML class diagram supports methods - our colleague maintains that a domain model must not contain "operations". I can understand domain modellers using a sub-set of a UML class diagram - but isn't it dangerous to assume people will refrain from including "operations" if the tooling they are using supports it?
Good question, the problem is that it depends on the definion of the terms, I think they differ slightly based on the sources.
I would agree with previous answer - domain models are for describing the problem domain, at least the part you need to develop a solution. You describe all the various entities, their relations and their behaviour. I think that this is also the view from the Domain Driven design perspective.
Data models on the other hand are used for describing the data in your system and relations or associations between them. This is useful for describing what needs to be stored in the system and might also give hints how. I think data models would apply for your "no operations" rule, because they are not important in this respect.
Domain Modeling (in the sense of Domain Driven Design) is all about modelling the behavior of the domain concepts, while Data Modeling focuses mainly on... data.
It doesn't mean that Domain Modeling ignores data structures. It just puts more emphasis on operations and how they can be uses to solve problems.
I don't know much about other than Domain Driven Design domain modelling techniques, but DDD involves (apart from modeling data and behavior) also explicit modelling of consistency boundaries (aggregates).
This is an old thread, but here's a slightly improved answer to clarify some of the others posted here.
The concept of 'domain' (and other kinds of models such as conceptual, logical and physical) is orthogonal to the technique used to represent the model (eg. ERD, UML etc). A domain model is essentially the same as a conceptual model, but different design methodologies might have slightly different terms and definitions. While it's common to draw domain models using UML or ERD to describe entities and their relationships (or classes/methods in UML), this only applies to modelling the information to be managed by a system - logically, the concept of domain modelling (or conceptual modelling, logical modelling or physical modelling, etc) can apply to any problem situation and a solution. Depending on the nature of the problem and the problem solving approach, other modelling techniques could be used to achieve the same goal.
In short, domain modelling and conceptual modelling are essentially the same thing, hair-splitting definitions aside. The concept applies to what the modeller is trying to communicate. The concept of data modelling (ie. ERD) or object-oriented modelling (ie. UML) refers to how the modeller communicates it.
I would say that a domain model describes the problems (what we want to manage/solve) on a given domain. The data model would describe the solution (how we're going to solve it) to the problem described on the domain model.
However, we are indeed in murky waters...