24

It is absolutely possible to have those values differ. If you have a sale to make to an important government agency that requires high performance but won't ever use module X, then it makes a lot of business sense to fix a minor database availability error sooner than a severe error in the X module. Basically, technical reasons are not the only factor when ...


18

This is a very glib answer, but getting right to the heart of the matter: In terms of DDD maybe think of reporting as a Bounded Context?, so rather than thinking in terms of "THE" domain model, you should be willing to think that it's okay to have more than one model. So yes it's okay if the reporting domain has reporting business logic in it, just as it's ...


10

Robert made good points in his answer. In addition, you might want to look at Audit Log as described by Martin Fowler here (and perhaps, more generally, Temporal Patterns). If you wanted to do more than just business activity monitoring / business reporting of these events, you might want to look at Event Sourcing. Fowler provides an introduction here. You ...


10

Do the easier of implementing the equation specified in the formula or spitting out the previous row's value, incorporating a prominent comment in the code explaining why it is as it is. At the same time, send your question back up the chain. If they get back to you with a spec change in time to implement it, then implement it. If not, your butt's still ...


9

No. That metric displays a fundamental misunderstanding of both testing and reliability. Testing can only ever prove the presence of bugs, but never the absence. A test suite demonstrates that a system is capable of functioning as expected (incl. known failure modes), but except in the most simplest cases can never prove that it will always work as designed....


7

When there is a dispute between the users and the program about how the program should work. The solution isn't to fix the users. That goes double when you're presenting data to domain experts. In this case if the devs and the users have different ideas about what data should be presented, then correct response is to make the data presented match the user's ...


7

If this is an actual business-related report that is going to be generated and given to someone, then generate event records into a database, and then create a report from those records. Give the records actual semantic meaning, rather than merely attaching a message. In other words, make them first-class citizens. Logging serves a different purpose. ...


7

You say "I didn't do any work for those features to work properly" but that's not strictly true. While you didn't write any code, you did spend some time testing, and testing is valid work just as much as writing code is.


7

Programmatically transforming Excel sheets is not the way to go. I would review the whole procedure completely and use a database as data source for the reports. Either let the users enter the source data directly into the database through an appropriate application or import the Excel data into the database (in an automated process). Once that data is in ...


6

Take notes. Think about why you have been asked to do this? Are you a new hire, tasked with becoming familiar before you do actual development? Are you a consultant? Is this a project for school? Think about the reason you have been tasked to do this, and write down (in a Word document or similar) the information that is most relevant to the task at hand. If ...


5

If the goal of the formula was to check for missing values, construct a test that should verify that the software can detect that a value is missing. If the formula is wrong, the test will not be successful. Then it can be flagged, investigated, and fixed.


5

If the purpose is to display on a page the first step is to limit the amount of data returned. No one can process 3 million rows at once, find ways to limit the data returned. Requiring search criteria or only returning X rows per page can drastically speed up performance with no real impact to usability. Ensure you are using SQL to create the result set, ...


4

My understanding from your question is this: Application for daily task has View >> Controller >> Model (BL) >> Database (Data) Application for reporting purpose View >> Controller >> Model >> Database (Data + BL) So change in BL for 'task application' will lead to change in 'reporting' BL too. That is your real problem right? Well ...


4

Reporting is a bounded context, or a subdomain, to speak loosely. It solves a business need of gathering/aggregating data and processing it to gain business intelligence. How you implement this subdomain will likely be a balance between the (most) architecturally correct way you can do this, and what your infrastructure will allow. I like to start on the ...


4

When you have time-dependent reports, which depend significantly on other time-dependent data like "when did which a team member belong to a team", you need to track the history of all relevant records if you want to get the reports right. And, of course, when you run the report, you have to tell the system for which date you want the report, so if you run ...


4

Now, since I didn't do any work for those features to work properly, in order to reflect correctly what was done for those tasks should I close them unassigned in the backlog directly or put them in the sprint, assign them to me and close them? IMO you did some work: you tested it. Therefore, I would include in the sprint, assign it to me and close it. ...


3

Date and time bugs Bug: Year-end processing will totally corrupt your database. That's clearly a severe bug. Date: December 15. The bug is very high priority. Date: February 1. The bug is low priority. Accidental launch of missile bug Bug: ICBM control software pukes when going from Feb 28 to Mar 1 in years divisible by 4. The result is an ...


3

What you need is graphviz digraph { ITEM_101 -> ITEM_75 ITEM_202 -> ITEM_77 } dot input.dot -Tpng > image.png


3

OK, This is not a problem of bounded contexts. You can have more than one service in a bounded context, and its impossible to say what should go in what context when you abstract the functionality to simple names like "A" and "B". The key thing to realise is that micro services should be micro or even nano your preference should generally be to add a new ...


3

Depending on how diverse your teams are and what the guts of your objective is, an approach to consider is: Providing one or two common reporting solutions to the projects and let projects that have more specific or divergent requirements create their own solutions. Implementing the one or two common reporting solutions as microservices, so that they stand ...


3

Have a listen to Greg Young's talk on Polyglot data; he may persuade you that you want a pull model, rather than a push model, for your subscriptions. Essentially, when the subscription "wakes up", it refreshes its local copy of the event history/histories from the book of record, and then writes out the new projection from those histories. If you store ...


2

Provide a counterexample, rather than a mathematical explanation, to the chain of command. That way they can immediately see that it's broken, even if they aren't mathematically inclined.


2

It's typical to separate operational/transactional data stores from reporting. The latter may have requirements to keep data for legal reasons (e.g. seven years of financial data for financial auditing), and you don't want all that in your transactional data store. So you'll partition your transactional data by some time measure (weekly, monthly, quarterly,...


2

It's 4 years later and I just found this question again, and I have what is, to me, the answer. Depending on your application and it's specific needs, your domain/transaction database and your reporting can be separate "systems" or "engines", or they can be serviced by one system. They should, however, be logically separate - which means they use different ...


2

What about the reporting side? Are data warehouses acceptable, or are they bad design because they incorporate business logic in the database and the very data itself? I don't think you are talking about business logic, this is more reporting logic. What do users do with the information on this screen, is it simply for status updates? Your domain model ...


2

First some terminology, what you call the task side is known as Transactional and the Reporting side is Analytics. You've already mentioned CQRS which is a great approach but there is little documented practical application of the approach. What has been heavily tested is supplementing your Transactional processing with an Analytical processing engine. ...


2

Here are two popular ones: pyPDF2 ReportLab As far as I know ReportLab has a free and paid version.


2

Anything that is worth printing at all is worth printing to the logs, since the whole point of logs is to record as much detail as possible about what happened during execution. As with any other program, by default the user should see only a small subset of the output that's likely to be useful and relevant to him. Due to the nature of your program, you ...


2

The fact that you are writing a console application doesn't change good UI practices. Your business logic should be distinct from your UI. The business logic performs the operations and indicates what might have gone wrong. The UI decided how that should be displayed. If there is information that is useful for tracking the execution of the application after ...


2

One solution to this is to report off 'events' sometimes called domain events. Rather than selecting from a relational database and having to ensure that it correctly models history, write your sales events to a flat table as they happen and run the report off that table. Then if the events need correcting, say they were recorded against team X when really ...


Only top voted, non community-wiki answers of a minimum length are eligible