Kind of in-memory/transactional Domain Events. Let’s start with the first model, though. The latter type of events can be used as “integration events” because its related data was persisted for sure, therefore, you could use any implementation of a EventBus.Publish() and publish asynchronously that event to any subscriber whether the subscriber is in-memory or is remote and out-of-process and you are communicating through a real messaging system like a Service Bus or any queue based system that supports a Pubs/Subs model. In the latter case, it really has happened in the past, from an application and persistence point of view. When discussing about “Domain Events” there’s certain lack of clarity because sometimes you can be talking about Domain Events that happened but within the same transaction scope of the operation that is still in memory objects (so I fact, it still didn’t happen from a persistence point of view) or, on the other hand, you could be talking about events that were already committed in your persistence storage and must be published because of state propagation and consistency between multiple microservices, bounded-contexts or external systems.
So, feel free to discuss about it with comments at the end of this post. I might evolve this post depending on feedback and some implementations we’ll be doing in the short/medium term. Integration Events patterns already published by the community.
SOA is at a higher level than DDD like "if SOA is the PC Architecture, then DDD is the Processor Architecture".This blog post is about comparing several approaches of Domain Events vs. But the domain model gives detail about repositories, Aggregates. Also, SOA never speaks about how u store objects or retrieve objects or aggregation of objects. The client doesnt need to know whether DDD is used or any other Model is used to Implement service. DDD is just a Domain Model.ĭDD just sits inside the Business logic layer of SOA. From what i understand SOA is a Distributed Application Architecture. Using the messaging features of a DBMS, like Sql Server Service Broker, is an entirely different matter and does fall under the "shared infrastructure" you mentioned. Regardless of SOA, I would not use a data source as a bounary between apps. Backdooring them through the database does not seem to fit that definition. Whose stored procs are those? Can the other application change them, or add constraints, triggers, etc? What if they do and it breaks your app?Ĭommunicating, in my book, means letting the listening party decide what to do with the information you send them. When two "applications" communicate, although I'd hardly call it that, through a shared data source (what's been called a database), then the boundaries where one application stops and the other starts gets blurred. There's a difference between sharing infrastructure like a DBMS, or physical database server, and sharing a data source. Often they also understand that each of those applications' implementations may be distributed - with parts of the application communicating with each other through a method of integration - file sharing, shared database, remote method invocation or messaging.ĭoes service orientation in the real world really make database or other shared infrastructure boundaries any clearer? Most basically understand the boundaries of their payroll, ordering and CRM applications. But 'application' is probably one term that most people can identify with reasonably easily. Your point about bluring boundaries is an important one IMHO, and certainly 'service' and 'component' are terms that are overloaded in use and understanding. On the question of orthogonality of DDD and a Service, I would suggest that just because you can use DDD, RAD or scripting to implement a Service, doesn't make them 'orthogonal'. So, whose database is it?Īnyway, good to hear your thoughts on the subject. For example, databases are often considered to be inside a distributed application, however they are also often used by other applications as well. Personally, I object to the term "distributed application" in that it blurs boundaries that are important. The only difference between orthogonal and "totally unrelated", in my opinion, is that orthogonal "things" have an intersection point - you yourself said it DDD can be used to implement a service.Īs to your point about "applications", I'd have to say that seeing as the terms "service" and "component" are ill defined, "application" shouldn't be much different.