I'm working on a proposal and prototype for a re-architecture of a complex system. It's an n-Tier distributed architecture that broadly follows the principles of DDD and has elements of Jeffery Palermo's Onion Architecture, especially the separation of the core concept of Domain Model/Services (these would be closely related to domain problems and some may ultimately be naturally implemented as remote WCF/Workflow services) from the higher-level concept of Application Model/Services (components which would typically be coordinating actions on behalf of application/UI code, and would be injected as dependencies in those applications).
I need to communicate this approach to executives and/or developers who have not been heavily exposed to service oriented architectures, SOLID principles, dependency injection, composite applications, etc. I'm encountering some significant resistance to the concept of an "Application Service" not being implemented as a WCF or "Web" service.
To me, "services" are simply components that implement some kind of "service contract" that "service consumer" and "service provider" can agree upon abstractly, and this does not imply that it's necessarily a "web service", listening on a port on some server. It seems that I simply can't get this point across, however - it seems too subtle or too abstract.
I think I just need another term for "Application Service" to distinguish it from "Web Service", but "API" or "SDK" or "Helper class" or similar terms that are well understood by my audience are either not accurate or don't seem to adequately describe the notion.
Any suggestions on what would be an good alternative term?
UPDATE: I've been reading recently about MVVM + Controller (MVVMC or MVCVM), and was beginning to think that perhaps some of our Application Service operations could really be considered to be Controllers. It's still not clear to me how validation (ie IDataErrorInfo) implementation would work in this world, though - would all business logic and validation be handled by the "Controller", possibly raising an event similar to (or in fact the same as) INotifyPropertyChanged.PropertyChanged?
Uncle Bob uses the term Interactors in his Clean Architecture approach. They are more or less equivalent to application services. Use Cases are another alternative.
When it comes to developers, Service is often used as a convenient umbrella term to describe pretty much anything stateless that exposes operations, often because people don't bother finding a better name. It's a shame, but I can't see what you can do about it. Using another word for application services with your developers will just reinforce their illusion that service == remote service temporarily - sooner or later, they'll discover the whole world thinks otherwise.
So the question is what's another term for "Application Service" to distinguish it from "Web Service":
What about "Business Service"?
or "Domain Service"?
Related
I am new to DDD and this is the first project for me to apply DDD and clean architecture,
I have implemented some code in the domain layer and in the application layer but currently, I have a confusion
now I have an API which is placeOrder
and to place the order I need to grab data from other microservices, so I need to grab production details from product service and address details from user profile microservice
my question is, should these data are pulled into the domain layer or in the application layer?
is it possible to implement a domain service that has some interfaces that represent the product service API and use that interface in the domain layer and it will be injected later using dependency injection or should I implement the calling of this remote API in the application layer?
please note that, calling product service and address service are prior steps to create the order
Design is what we do when we want to get more of what we want than we would get by just doing it. -- Ruth Malan
should these data are pulled into the domain layer or in the application layer?
Eric Evans, introducing chapter four of the original DDD book, wrote
We need to decouple the domain objects from other functions of the system, so we can avoid confusing the domain concepts with other concepts related only to software technology or losing sight of the domain altogether in the mass of the system.
The domain model doesn't particularly care whether the information it is processing comes from a remote microservice or a cache. It certainly isn't interested in things like network failures and re-try strategies.
Thus, in an idealized system, the domain model would only be concerned with the manipulation of business information, and all of the "plumbing" would be somewhere else.
Sometimes, we run into business processes where (a) some information is relatively "expensive" to acquire and (b) you don't know whether or not you need that information until you start processing the work.
In that situation, you need to start making some choices: does the domain code return a signal to the application code to announce that it needs more information, or do we instead pass to the domain code the capability to get the information for itself?
Offering the retrieve capability to the domain code, behind the facade of a "domain service" is a common implementation of the latter approach. It works fine when your failure modes are trivial (queries never fail; or abort-on-failure is an acceptable policy).
You are certainly going to be passing an implementation of that domain service to the domain model; whether you pass it as a method argument or as a constructor argument really depends on the overall design. I wouldn't normally expect to see a domain entity with a domain service property, but a "use case" that manipulates entities might have one.
That all said, do keep in mind that nobody is handing out prizes for separating domain and application code in your designs. "Doing it according to the book" is only a win if that helps us to be more cost effective in delivering solutions with business value.
The problem I'm facing is the design of an integration platform.
The company has different tools used for selling online financial services and wants to unify the selling process by creating a common integration platform.
Existing tools range from simply designing a tailor-made offer, to managing all the phases of listing to selling and supporting. The integration platform should orchestrate all the tools.
So I do approach this problem from a DDD point of view?
Domain: selling online services
subdomains: service catalog, request offers, sending offers, buying service, support customer.
bounded context? maybe integration with other company systems like identities and invoices?
My trouble with this is that some existing applications encompass several subdomains, others don't. Also, some applications working in the same subdomain have completely different languages, for example, service vs product, vs project...
How does an integration platform fit in this picture and how would you approach it from a DDD point of view? (or maybe it's a completely wrong approach and should I leave DDD inside each tool and treat them as bounded context?)
I recommend extracting the common bits of meaning (ignoring their names) from the various applications into common domains/bounded contexts. Each bounded context has anti-corruption layers that essentially adapt the language used in one or more existing applications to the one used in the common domain (and vice versa). Then you can cut over the existing applications piece-by-piece to use the respective ACLs to take advantage of the common domain implementation.
Eventually, you might even be able to dispense with the ACLs, as the language becomes more ubiquitous, but it's also perfectly okay to keep them around forever: the ACLs introduce some indirection (and possibly complexity, e.g. if they're deployed as their own microservices) but that's the price you pay for limiting coupling to the ACL.
(It's not clear from the question how experienced you are with DDD).
Background: an international company with a federation model is transforming into Microservices due to chronic Monolithic pain. Autonomous teams with quick deployment is highly desirable. In spite of theory, services are indeed dependent on each other for higher functionality, but are autonomous (independently developed and deployed). Since this is a federation model and decentralized control, we cannot impose strict rules - just like the UN. Without a governance platform that will manage dependencies else due to the multiple versions in production in different countries, we foresee uncontrollable chaos.
Let's call set of Microservices that needs to collaborate a "Compatibility Set". A service can be deployed but may not satisfy the higher functionality in its Compatibility Set. For example MicroService A-4.3 is fully autonomous, deployed and working perfectly. However to satisfy BusinessFunctionality 8.6 it must work together with MicroService B-5.4 and MicroService C-2.9. Together (A-4.3 , B-5.4 and C-2.9) they form a "Compatibility Set"
There are two approaches to this dilemma. Microservice in real life where the rubber hits the road and the learning from experience begins...
Approach 1) Governance Platform
Rationale: Federal model in an International company in 100+ countries. Which means Central IT can lay down the model but individual countries can choose their own destiny - and they frequently do. It frequently devolves to chaos and the Central IT team is on the hook. DDD is the solution for an ideal world where version inconsistencies do not derail functionality like releasing services which do not fit into the Compatibility set, individually blameless but together they fall apart or result in flawed or inconsistent functionality.
There is no homogeneity, there isn't even standardization of terminology
Developers are mixed skill, many junior, and many learning reactive programming and cloud native technologies
Bounded Context heavily depends on Shared Vocabulary and it can get subtle, but this is impossible to enforce and naive to assume in an International, mixed skill, fragmented scenario with multiple versions running
Standardization on a Single Business Model is not realistic in such a heterogeneous system (but ideal)
How what is Central IT to do when they're held responsible for this Chaos?
Enforce a Governance Platform
Create a Microservices governance system or framework to enforce dependency management. It verifies and enforces at design and run time dependencies on a particular Microservice through a manifest and performs some checks and balances to verify the service implementations being offered - the "Compatibility Set".
Approach 2) Domain Driven Design (DDD)
DDD is about modelling domains that are constantly evolving, where domain experts (typically a business stakeholder, or perhaps an analyst) will work alongside developers to design the system. Within each domain, a ubiquitous language is formed, such that within that context, the same word always means the same thing. An important thing to realise is that in one part of your system, “Order” might mean one thing, it might mean for example a list of products. In another part of your system, “Order” might mean something else, it might mean a financial transaction that happened. This is where the model you describe can fall down, if my service needs to get a list of orders, perhaps there is a capability out there that supplies a list of orders, but which orders are they? The list of products or the financial transaction? Trying to coordinate as many developers as you have to all use the same language here is an impossible task that is doomed to fail.
In DDD, rather than trying to manage this at a system level and force every service to use the same definition of Order, DDD embraces the inherent complexity in coordinating very large deployments with huge numbers of developers involved, and allows each team to work independently, coordinating with other teams as needed, not through some centralised dependency management system. The term used in DDD is bounded contexts, where in one context, Order means one thing, and in another bounded context, Order can mean another thing. These contexts can function truly autonomously – you describe your services as being autonomous, but if they have to match their definition of order with the entire system by registering and supplied dependencies to a central registry, then really they are tightly coupled to the rest of the system and what it considers an order to be – you end up with all the painful coupling of a monolith, with all the pain of building a distributed system, and you won’t realise many of the benefits of microservices if you try to take this approach.
So a DDD based approach doesn’t ever try to take a heavy handed approach of enforcing dependencies or capabilities at the system level, rather, it allows individual teams to work without needing central coordination, if Service A needs to interact with Service B, then the team who manages Service A will work with the team that manages service B, they can build an interface between their bounded contexts, and come to an agreement on language for that interface. It is up to these teams to manage their dependencies with each other, at the system level things can remain quite opaque / unenforced.
Too often we see people implement “Microservices” but end up with a system that is just as, if not more inflexible, and often more fragile, than a monolith. Also called a "Minilith" or "Monolith 2.0" Microservices require a complete rethink of architecture and software development processes, and require not just allowing services to be autonomous and independently managed, but also for teams to be independent, not centrally managed. Centralising the management of dependencies and capabilities in a system is likely to be an inhibitor to successfully building a microservice based system.
Intelligent and Pragmatic comments invited...
Approach 1 (Governance) is pragmatic and tactical and intended to solve very real challenges. Question is - will it undermine the long term strategic DDD model of the Enterprise?
Approach 2 (DDD) is ideal and aspirational but doesn't address the very real challenges that we have to deal with right now.
Opinions? Thought? Comments?
I've seen multi-national companies try to cooperate on a project (or be controlled from a central IT team) and it's a nightmare. This response is highly subjective to what I've personally read and seen, so it's just my opinion, it's probably not everyone's opinion. Generally broad questions aren't encouraged on Stack Overflow as they attract highly opinionated answers.
I'd say DDD probably isn't the answer. You'd need a large number of a developers to buy into the DDD idea. If you don't have that buy-in then (unless you have a team of exceptionally self-motivated people) you'll see the developers try to build the new system on-top of the existing database.
I'd also argue that microservices aren't the answer. Companies that have used microservices to their advantage are essentially using them to compartmentalise their code into small, stacks of individually running services/apps that each do a single job. These microservices (from the success stories I've seen) tend to be loosely coupled. I imagine that if you have a large number of services that are highly coupled, then you've still got the spaghetti aspects of a monolith, but one that's spread out over a network.
It sounds like you just need a well architected system, designed to your specific needs. I agree that using DDD would be great, but is it a realistic goal across a multi-national project?
I also dealt with the problem described in the question. And I came up with an approach in which I use API-definitions like OpenAPI-definitions to check compatibility between two services. The API-definitions must be attached as metadata to each service and therefore it is possible to do the check at run and design time. Important is that the API-definitions are part of the metadata as well when the API is offered and when the API is used. With tools like Swagger-Diff or OpenAPI-Diff it is possible to do the compatibility-check automated.
I'm interested in the history of distributed, collaborative, cross-organisational programming paradigms - web services and SOA are de-facto now, but what came before? What models have been superceded by SOA?
Thanks
Well, I suppose there was RPC - which is really what SOAP is, only they didn't piggy-back the data payload on top of a standard protocol (http in SOAP's case). So CORBA and DCE-RPC and ONC RPC all did the same thing, but only over internal networks, not over the internet.
There was also EDI as a 'standard' for exchanging data between disparate entities. This was effectively a way of defining what the data payload would look like (similar the the XML part of SOAP).
But these are still not SOAs really, they provide the same functionality but the big difference was how people thought of using them. Once you could write a machine-to-machine 'website' and have different machines talk to each other through them, it took off. You could do it before using CORBA, say, but it wasn't as easy or as widely known about. You can tell this has happened by the fact we have several terms used for effectively the same thing - SOA, SaaS, Web Services... all the same thing (but lots of money to be made 'consulting' on the difference ;) )
Maybe Silos?
...where services are just not shared across an enterprise, at least in a standard way. This is why products like BizTalk are used: to get silos to talk to each other via standard interfaces.
I don't really think you'll find anything that's been superceded by SOA. You will find that there's been progress in organizing computer programs to take advantage of the SOA type principles. As for programming models that have been in reasonably common use, well, let's see... CORBA, RPC, more generic client-server applications. Of course, computer-to-computer communications were preceded by process-to-process communication using a wide variety of conventions.
SOA as a philosophy of breaking large problems into smaller ones and then composing the results has been known and applied since humans started making bricks instead of building complete walls. Of course, that was mostly implicit. Explicit statements for SOA really started to come about with CORBA and, while SOA is independent of Web Services, the advent of HTTP and XML, and then SOAP, really started to make development of non-specialized "services" easier, more worthwhile and thus common.
This pdf A Note on Distributed Computing should be an interesting read. It is pre-SOA and would give an idea of the history up to that point (1994).
I would say distributed object technology. And before it remote procedure calls.
RPC is one of the earlier approaches and gained popularity from the Sun implementation. One of the famous uses is NFS (network file system).
As object oriented programming became more popular, distributed objects followed. Most important was Microsoft DCOM (and later COM+) and, more industry wide, CORBA.
SOA is a divide and conquer approach that is critically dependent on the concept of services. Which is different from objects as used by CORBA et al, as well as being different from resources as in REST.
Objects are created and their lifetime is typically controlled by the client. On the other hand, services are assumed to be always there provided by the server. This is one reason why SOA is not equivalent to distributed objects.
Services are also stateless, which means that the server when considering the response to a service request need not look at the history of interaction with the client. This was not a consideration when originally devising the RPC concept as scalability wasn't such an important issue then. Interestingly, large scale users of RPC did notice the relationship between scalability and statelessness. The NFS RFC explicitly mentions stateless servers, though with reliability as the main concern. Anyway, statelessness is one of the main difference between services and plain old RPC.
In short, no. I don't believe in the revisionist history of SOA being since the dawn of time. Any more than the universe being written in Lisp (or Perl for that matter). Nor is it equivalent to divide and conquer or division of labour.
SOA started as a concept at some point in the nineties. Overlapping with the development of CORBA. It is much harder to pinpoint an actual date or event and there are more than a few claims to the conceptualisation of it.
Having recently discovered design patterns, and having acquired the excellent Head First Design Patterns book (can really recommend it!), I am now wondering about design patterns for security and controlling access to records in data stores.
My use case is a bespoke CRM style application, with contacts, businesses, and users who have different levels of access, including being limited to read only access, or even a subset of records. I will only be doing distinct entity level access control, not field level.
Can anyone recommend any security orientated design patterns that would fit the above?
If it makes a difference, I am using ASP.Net MVC, Entity Framework 4 and SQL Server 2008.
Security is what we call Cross-cutting concern and it's never easy deal with.
If you need to deal with the security from ASP.NET MVC level you would consider to look at MVC tutorial :
http://www.asp.net/learn/mvc/
If you want to know more about the security from the domain model level, an interesting question was already asked :
DDD User Security Policies
Hope this helps
There does exists a group of patterns realted to security, though most of them fucuses on securing integrated systems. I have found no book that is as well written and usable as GOF/Head-first, though I did enjoy the one online at www.securitypatterns.org.
Security is as much about architecture (sever setup, network topology...) as its about programing, so I would recommend that you start out with a general security book. Also pick up a book specifically on .NET/Windows security, since robust security programming is very technology specific (I, as UNIX/Java programmer, will have a completly different toolbox than
a .NET programmer and can unfortunatly not help you with a book on this last subject).
A good place to start on security (although not necessarily a "security design patterns" book) is Ross Anderson's Security Engineering.