The microservice architecture is well known and will not be repeated here. When we create microservices, we need to create a microservice with high cohesion and low coupling. The bounded context in DDD perfectly matches the requirements of microservices, and the bounded context can be understood as a microservice process.
The above is to describe the similarities between the two from a more intuitive point of view.
After the system is complicated, we all need to use divide and conquer to disassemble the problem. There are generally two ways, the technical dimension and the business dimension. The technical dimension is similar to MVC, while the business dimension refers to dividing the system by business areas.
The microservice architecture emphasizes dividing and conquering from the business dimension to deal with system complexity, and DDD also focuses on the business perspective. If the goals (business dimensions) pursued by the two achieve the unity of the context, what are the connections and differences in specific practices?
DDD is a strategy based on modeling your business using OOP, implementing business requirements directly within the model. DDD helps building software more effective, by allowing better mutual understanding between software programmers and business experts.
Microservices is a software architecture. It drives how to technically structure your software to achieve good execution performance, scalability, security and maintainability of a growing code base without expanding the technical debt. It helps building software more efficient.
Actually the two concepts are very orthogonal although both are needed for good software quality. You could, however, make a non DDD microservice, or a monolithic DDD application.
In my opinion, when we think of distributed systems and microservices we think of DDD as well. Both approaches don't live alone, they are a complement of each other.
There are a lot of reasons why we segregate our applications in microservices, which may get for business or technical approach and we always use the DDD concepts to translate the business world for our tech world.
Related
In a context of several spring boot apps, sharing some components, is that considered as a bad practice to publish an artifact used in those apps?
I'm planning to reuse controllers and services abstracts and low level classes (for statistics requiring fast write access, so webservices are excluded).
There are two contrary paradigms, both definitely make sense on their own, but in this case they front each other. Hardcore microservice evangelists would roughly claim that there should be no common dependencies at all to reduce coupling between the different services / applications. That means although in case the services share many architectural patterns, you have a lot of "copy and paste" code. And exactly that would make the don't repeat yourself faction angry, because it makes also sense thinking about why not sharing already implemented functionality.
So the correct answer is: "It depends." It will always be a tradeoff between following the one law by violating the other. You can just make an economical / cost-effective decision and figure out what is feasible for your infrastructure and what causes less technical debt.
Suppose I have a very large-scale server-side web application written in JavaEE (and related technologies classically combined with it), and I decided to migrate it completely to Akka (and related technologies usually combined with it, including moving the code to Scala). The reasons of the migration decision are not important: suppose I have to do it, and that's all to it.
My question is: What would be the strategy to follow here, aiming to optimize the migration time and the scalability of the resulting application?
If the question lacks of details, I can provide some, although I would like to hear strategies without being very specific.
This is an open ended question. But let me try and give you some ideas. Having worked with both J2EE as well as Play2/Akka/Spray.io (Scala) based system I can provide you will the following high level/general guidance for migration.
Partition your system: Partition your current system based on functionality and rank them according to their criticality to business, your stakeholders and clients. Partitions can done based on different dimensions ( architectural components at runtime, business features, development team/modules) etc. You also need to find dependencies between these partitions.
Identify candidate partition: Once you have ranked partitions, it’s useful to pick the smallest possible partition that overlaps in as many dimensions as possible and has the least amount of coupling. Usually this is the case if your initial architecture is modular.
Implement a prototype: Take the candidate partition and create a prototype that provides the same functional capability. Now evaluate and compare the new capability against the old in terms of various quality attributes (performance, modifiability, extensibility etc). The prototype will also give you an estimate of technical risk, challenges, and effort.
Create a new architecture: I think at this point you should have enough input to create the first version of your new architecture. Also identify how capabilities of other partitions will be implemented in this new architecture. Selecting the most complex partition and try to map it to this new architecture is really good exercise and can massively reduce your technical risk in the future.
Field the prototype: Try to field the prototype to a small subset of users/stakeholders and get feedback. Decoupling the prototype using REST/pub-sub interfaces is a good idea.
Plan for migration: Create a plan and schedule for rest of your system.
I can be more specific if you provide more targeted questions.
The project, I am currently working for and based on a Java-Web stack (Spring, Hibernate, HTML5..), is using the approach of Domain-Driven-Design principles for design and development.
Our team is asked to implement an accounting system that will respond to business events (like requesting a payment to a customer or receiving the payment) by creating and storing accounting entries. It seems that the accounting patterns of Martin Fowler advocates the usage of an event-based system. So my question is the following :
Are domain events the right approach to use for this purpose ?
If yes, what are the benefits compared to the time to implement a new Event mechanism in our project ?
Thank you very much for your help.
Accounting is typically a downstream bounded context in DDD parlance. This means that accounting actions are created in response to events from other systems. As you point out, Martin Fowler's accounting patterns reflect this as well.
Whether a domain event infrastructure as described by Udi is the right approach depends on what your current system looks like. What Udi describes is a framework for publishing domain events directly from domain entities. If this is the preferred approach for you then go for it. What you should take into account is 1) the described framework isn't trivial - you have to take care of threading issues as well as transactions, 2) it addresses publishing events within a single process and you if you need to publish to other systems you will need to implement a dispatcher.
The important takeaway is the concept of the domain event itself - an indication of something "interesting" happening in the domain. An event-driven modelling methodology is a shift in paradigm from other approaches. How they are published is of lesser importance.
What are these in Java EE
.Presentation Tier
.Business Tier
.Integration Tier
I like to know what are these patterns with example
Presentation tier: what the users see, typically a web application.
Business tier: where all the logic for your application is performed.
Integration tier: what connects the system to other systems (through database connections, JMS, web services, etc).
Mulit-tier architecture, or n-tier architecture, is an architecture style in which the different responsibilities of an application are broken up into distinct tiers, typically:
The presentation tier for user interface generation and lightweight validation.
The business tier for heavyweight processing, validation, business
rules, workflow and interfaces to external systems.
The integration tier for data transformation and persistence services.
The rationale behind n-tier architecture is better Separation of Concerns (SoC) and low coupling. This allows better scalability as each tier can be separated onto different computer systems distributing the processing load.
Note that tier may have different meanings for different people: one hardware oriented (physical), the other software oriented (logical). Personally, I think that there is indeed a difference and prefer to use the term "layer" for the logical view. This is reminded in mulit-tier architecture on wikipedia:
The concepts of layer and tier are often used interchangeably. However, one fairly common point of view is that there is indeed a difference, and that a layer is a logical structuring mechanism for the elements that make up the software solution, while a tier is a physical structuring mechanism for the system infrastructure.
Actually, multi-tier architectures have been highly promoted by hardware vendors (Sun, I'm looking at you) as more tiers = more machines, despite the consequences on the complexity and the productivity. So please, don't follow the Core J2EE patterns to the letter, you don't need all the patterns unless you want to build a Rube Goldberg machine.
Examples:
Presentation tier: JSPs, Servlets;
Business tier: Java classes for connection to databases, EJB;
Integration tier: SOAP, REST Web services
Is it good for develop MVC Framework by using J2ME (Resource,Speed,Performance,...)?
MVC is especially appropriate for Mobile applications. These typically have a substantially larger number of specifically purposed user interface modules due to real estate constraints. So the more rigorous attention to SOC that is implied by good MVC design makes keeping the design more tightly focused on single-purpose units that are consistent in their abstractions and play well together.
At the same time, this pattern helps partition functionality into modules that can more cleanly defined with solid coherence while being more precise about limited cohesion where it properly belongs.
Yes, MVC eases the design process and promotes portability. Check out PureMVC . The J2ME version is in alpha. Nokia is using it.