Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a monolithic app that does the following logics:
Get a list A (Customer) from database
Validate data in A using some criteria, if it's not validated, throw an error
Do some operations on A to get a list B (e.g. Regional customers)
Do sth with B
Now I am transforming my app using microservices, but I have trouble in designing the calls.
As B can be deduced from A entirely, I want to just make a single micro service getCustomerA that returns all the dataset A. That means a single database access is needed. That will be a performance plus.
But the problem is, the operations on A to retrieve list B is also part of the business code. So it's more logical to put these codes in Customer microservice side, if we follow domain driven design, in microservice Customer, maybe getRegionalCustomer.
So I want to know, what is the best practice in this case ? Should we priotize the single database call (first case) or it's better to do two calls (but in this case, 2 database calls) ?
Since this is mainly opinion based I can only give you that :-)
From my experience splitting the app into microservices just for the sake of doing it puts technical dogma over technical simplicity and often introduces a lot of unnecessary overhead.
With regard to the database calls I can also tell you from experience that quite often you win performance when doing two simple calls over doing one overly complex one. Especially if you start introducing big joins over many tables or - ouch - subselects in the on clause.
See if the most simple solution works and keeps the code tidy. Constantly improve quality and optimize when the need for it arises. If you have a piece of logic that warrants to be split of into a microservice (e.g. because you want to use a different language, framework or want to offload some calculations) then go for it.
Domain driven design does not tell that each boundle context only can contains one entity, in fact, a bounded context (or microservice) can contains more than one entity when these entites are clearly related, in other words, when they need to be persisted transactionally.
In your case, due to the tight relation between the two entites, the best way is to build only one microservice that do both operations
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
In order to understand the following question you need to know that I'm a complete novice in the whole Spring Boot ecosystem, as well as, the architectural philosophy behind it.
Task
The app I'm developing with Spring Boot requires, on a business level, some data which are simple collections stored in Firestore. Now, the user when inputting some parameters on the front end (the REQUEST method) and asking for the execution of a certain algorithm on the back-end will trigger the following:
1. The business logic part of the app is going to retrieve some data from the database based on the user input.
2. It's going to process this data and create a RESPONSE based on the retrieved data and a number of other user input.
The problem
So, I'm not really sure if I should be even bothering with creating a service connection for the database since the only one accessing it will be the business logic layer. The database will primarily be build for reads only while at the same time I want to leave open the possibility of later creating a system for auto-updating it (again, only from the back-end, no user interaction/input). Also, what I'm possibly forgetting is the support for multiple connections. Each user may trigger the main algorithm to run utilizing a different set of data retrieved from the database. In that vein, while I would love to leverage the capabilities of Firestore, is the use of it justified in the sense of the data being static for the time being?
You should strive to keep the business logic as pure as possible from implementation choices. Ideally your business logic should not talk to network, file systems or databases. It should be just the pure, refined business logic.
You will then have outer layers that abstract as much as possible these external dependencies. In the case of database, usually you'd have a persistence layer of sorts, which is responsible for accessing directly the database.
For instance, lets say the business logic needs a list of clients sorted by last name. From the business perspective, they're calling a method fetchClientsSortedByLastName() and what that method does is a black box. If at a later moment you decide to switch from Firestore to Postgres or Mysql, you only need to change the persistence method. The business logic will remain exactly the same.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have three micro services MSA, MSB and MSC. The micro service MSA creates a partial object O1 and sends to MSB only through a dedicated message topic. After receiving the partial object O1 from MSA, MSB populates few more attributes in O1 and shares in the common message bus from which MSC consumes the object O1.
Question is that, is this a good approach where the object building is shared across multiple micro services?
Here it's your response:
In object-oriented programming, a God object is an object that knows too much or does too much. The God object is an example of an anti-pattern.
A common programming technique is to separate a large problem into several smaller problems (a divide and conquer strategy) and create solutions for each of them. Once the smaller problems are solved, the big problem as a whole has been solved. Therefore a given object for a small problem need only know about itself. Likewise, there is only one set of problems an object needs to solve: its own problems.
So you have a microservice Ordering and a microservice Pricing. Both of the microservices need information about the Product entity.
You should ask yourself:
Do those two different worlds realize the Product entity in the same way? Both of them need the same information?
Will the product information change for the same reasons for both of the microservices?
If no (which is likely the case), you have to add an abstract layer between them, so that you are sure that they use the same language.
If yes, you can keep on sharing the same object.
By the way, these concerns that you have is not a new thing.
Here is Martin Fowler's article about bounded contexts
So instead DDD divides up a large system into Bounded Contexts, each
of which can have a unified model - essentially a way of structuring
MultipleCanonicalModels.
keywords for further research: DDD, context map, bounded context, anticorruption layer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I currently have several "manager" classes in a project I am working on but have seen a lot of things that advise you to not use manager classes but don't seem to provide any alternatives in my situation. I have a ClickManager which contains a map of "clickable" objects and a ConfigManager which is responsible for loading and saving config files as the config class comes from an API I am using and is too stupid to load itself.
What are some alternatives to using "manager" in these cases?
Ward Cunningham once said (1) that every programmer should have a dictionary and a thesaurus on his or her desk. There's also a saying that there are only two hard problems in computer science: cache invalidation and naming things. (2)
The point is that naming things is important, and it's hard, and it's often neglected. This is why there are classes named Data and Manager littered around many code bases.
There are at least two potential things going on here. One is that the class is doing something reasonable, and it just needs to have a good, concise, descriptive name applied to it. For example, with ClickManager, does it dispatch events to the clickable objects? If so, maybe it's a Dispatcher. Does it lay out the clickable objects? Maybe it's a Positioner. Does it contain the clickable objects (as Erwin Bolwidt suggested)? Maybe it's a Container. Does it execute something in response to a click? Maybe it's an InteractiveCommand. It's sometimes helpful to think more specifically about what a class is doing in order to come up with a good name.
Another possibility is that the class has too many responsibilities, that is, it violates the Single Responsibility Principle. This is often the reason that something is hard to name, because it does a bunch of different stuff. Suppose the class simultaneously contains clickable objects, dispatches events to them, positions them, and executes commands. It's no wonder that it's hard to come up with a name other than Manager because it's doing all of these related, but independent functions. (Note that in many UI toolkits, these responsibilities have been separated into different classes.)
If this is the case it might be advisable to do some refactoring of a big Manager class into smaller classes, each of which has fewer (or one) responsibilities. It should be easier to come up with better names for those classes.
(1) I think it was at an OOPSLA about ten years ago.
(2) And off-by-one errors.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I need to persist objects and I want to keep my data classes as clean as possible. The persisted classes do not feature any business-logic code, but only data with getters/setters.
I'm currently implementing a solution with the Observer pattern. Each time an Observable persisted object is modified, it fires a message to an Observer object that takes care of persistence. This way, the only constraint for the persisted object is to be "Observable". It keeps things clean.
Another solution (maybe better?) would be to implement some DAO pattern, and I'm not very aware of the way it works. Maybe it would look like persistedObject.save(); or persistedObject.readById(id);. But it means I would have to define some DAO interface and then to implement the read/create/update/delete method in each and every persisted class
There are many, many, many answers to this question, data serialization or persistence is a core problem in software engineering. Options include using databases, memory mapped files, binary and textual formats, and more.
My personal favorite for quickly persisting objects is GSON, however your use case will dictate what works best for you.
You mention wanting design patterns for persisting Java objects, and while such patterns are approximately as numerous as there are libraries, here are a couple general suggestions:
Use immutable objects
Use the transient keyword for any fields that are not necessary to reconstruct an object
Avoid defining sanity checks or otherwise limiting the range of acceptable values in your objects - an instance constructed from a deserialize call may not correctly trigger your checks, allowing possibly invalid objects to be constructed
Use your serializable objects to construct more complex objects if you need more sanity checking, e.g. serialize a StubPerson POJO, and have a Person object that can be constructed from a StubPerson only as long as the stub's values are valid
I don't know if it fits for you but since you have only bean classes you could use the Java persistence api.
The DAO pattern is the best one to manage data access and persistence as it has been designed specifically for that.
Considering your needs you will probably have to couple it with some factory pattern in order to manage the different implementations (persistence adapters).
I don't know your requirements but if your application can be used by many persons at the same time you will have to care about concurrent accesses and define a policy (transaction, locking, etc... otherwise people will overwrite data each others).
Regarding your question i'd suggest JDO (with data nucleus as implementation) but the learning curve may be too expensive for your effective needs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I just wrote a long (and messy) blogpost about my view on domain-driven design at present day, with frameworks like spring and hibernate massively in use.
I'd ask you to spot any problems with my views on the matter - why this won't work, why it isn't giving the benefits of DDD, why it is not a good idea in general.
The blogpost is here (I don't think I need to copy-paste it on SO - if you think I should, tell me).
I know the question is subjective, but it is aimed at gathering the most predominant opinions.
(I'm tagging Java, since the frameworks discussed are Java frameworks)
I've just spent a year of my life ripping apart an application to eliminate an anaemic domain anti-pattern and its mis-use of Hibernate.
I can say without a doubt that the code that comes as a result of DDD is much easier to understand and refactor. In our case, the removal of a myriad unnecessary getters & setters, the increase in encapsulation, the concentrating of business logic, and resulting (dramatic) simplification of the services layers that come along with DDD have made the system so much more easy to maintain that now I believe we will be able to finish it, whereas before it was dragging on into forever. We've reduced the line count of this application by 50% without removing any functionality.
I also believe that the entire point of an ORM tool is so that my business logic is uncluttered with persistence code. When we had an anaemic domain model, we had a DAO for every domain class, now we have a small handful of DAOs as an entry point for CRUD on the "major" domain classes, but the other "minor" domain classes are handled by their parents...not because persistence logic is in the parent but because Hibernate transparently reacts to the business logic and makes everything Just Work.
In short, I can't answer this SO question because I emphatically agree with your post 100%...and am living it every day.
We go with the "anemic model" approach so that we can reuse the same models with different business logic. However, we do include calculations and helper methods within our models if they're applicable for all cases. But we do not inject anything into our models and do not inject our models into IoC.
Personally I'm not convinced that the part about injecting repository objects into the domain objects (meaning the persistent entities) is necessary with Spring and Hibernate. Hibernate is already providing persistent collections that can do lazy loading, so you already have the ability to traverse the domain model in a way that separates data-access infrastructure from business logic. I don't see what value tacking repositories onto the domain model is adding.
EDIT: Oops, posted this before reading the whole article. Now that I've read the entire blog post I think I'm in agreement with it. I like the part recommending doing without DTOs wherever possible.